А нет тогда?

Гет*

Добавляет в получаемый КОНТЕКСТ параметры для запроса.

По сути хелпер.

Но смыла в этом особо нет.

Не, я понял! Идея кстати супер

Но может быть только один запрос же.

Подобное только для execute делать смысл есть.

Погодите, так вы хотите так вообще все функции перечислять?

Погодите, так вы хотите так вообще все функции перечислять?

Ты про методы API?

Толко вот контекст можно сделать так, а может быть генсерверлм, в котором токен перманентно хранится

Да.

Да, про методы Апи

Да, про методы Апи

А как иначе? Иначе НЕКРАСИВО и НЕУДОБНО.

Ну как неудобно...

API.call("users.get", user_id: 1)

Но в ответ мы хотим получать структуру %VK.User

Да может просто JSON?

А смысл тогда во враппере?

Не, неправильно сказал

Я понял, отдавать карту обычную.

Как он там.. %{} обычный

Но суть в том, АПИ вконтакта местами просто пиздец.

ola

Отдаёт данные в крайне неудобном формате.

Шалом

Привет!

И суть как раз в стандартизации отетов, etc.

Мм..вот она цель!

В одном месте там ID пользователя строкой возвращается, в другом интом.

Ну, это далеко не самое плохое, что там есть, лол.

Я думаю так. Авторизируемя, получаем сервак глобальный с токеном Vk.authorise(login,password, user: pasha) Потом Vk.as_user("pasha") |> Vk.Users.Get(1373748) |> Vk.Request.add_parameter("chto_to", 123) |> Vk.Query или Vk.Query_async(to: self()) И если асинхронно то > flush %Vk.User{....}

> add_parameter

Зачем, если можно в get передать?

На всякий случай там, Может и не надо такого

Я думаю так. Авторизируемя, получаем сервак глобальный с токеном Vk.authorise(login,password, user: pasha) Потом Vk.as_user("pasha") |> Vk.Users.Get(1373748) |> Vk.Request.add_parameter("chto_to", 123) |> Vk.Query или Vk.Query_async(to: self()) И если асинхронно то > flush %Vk.User{....}

Думаешь, есть смысл делать пулл юзеров???

Просто имел ввиду что в цепочке можно ещё помодифицировать как то запрос

Просто имел ввиду что в цепочке можно ещё помодифицировать как то запрос

В этом как раз нет необходимости.

Пуль юзеров может иметь смысл. А может и не иметь)

Я просто предлагаю пока что

Лонгполл-сервер вконтакта пересланные сообщения возвращает в таком формате вообще: 305474979_1513511:(305474979_1513510),305474979_1513512:(305474979_1513498:(86711420_1433998,86711420_1433999),305474979_1513499)

Но если запросить информацию о сообщении по его ID у API, то он вернёт вложенный JSON.

Лонгполл-сервер вконтакта пересланные сообщения возвращает в таком формате вообще: 305474979_1513511:(305474979_1513510),305474979_1513512:(305474979_1513498:(86711420_1433998,86711420_1433999),305474979_1513499)

Поддержка говорит, что для УВЕЛИЧЕНИЯ СКОРОСТИ РАБОТЫ.

Ну так все правильно

Лонг полл не надо данными засорять

Они могут и не понадобиться

Эм, я не об этом.

То есть данными засорять?

Зачем мне например вложенный жсон в лонг полле, если мне иерархия пересылок не нужна?

При необходимости всегда можно получить

Зачем мне например вложенный жсон в лонг полле, если мне иерархия пересылок не нужна?

У тебя в любом случае вложенный ответ с сохранённой иерархией.

Только в нем нету кучи текстовой информации

При необходимости всегда можно получить

ВК лимитирует количество запросов к АПИ в секунду.

Только в нем нету кучи текстовой информации

И там тоже нет, в этом-то и дело.

ВК лимитирует количество запросов к АПИ в секунду.

А тебе очень часто нужно иерархию пересылок получать?

Мне вообще её не нужно получать, суть не в этом. ИЕРАРХИЯ ПЕРЕСЫЛОК сохранена в тех данных, которые возвращает лонгполл-сервер.

Она очень сокращенная

Я про то, что если запросить их напрямую, то вернутся эти же данные, только в нормальном формате.

Очень сомнительная оптимизация.

Ну апи то в основном для телефонов

Там трафик до сих пор важен

Лол, блядь.

305474979_1513511:(305474979_1513510),305474979_1513512:(305474979_1513498:(86711420_1433998,86711420_1433999),305474979_1513499)

Представь это в жсоне.

Разницы практически нет.

И это все отличие?

Лол, тогда реально дебилизм

И это все отличие?

Для этой параши нужно писать парсер.

Который вряд ли распарсит это быстрее, чем какой-нибудь poison распарсил бы аналогичный пейлоад в JSON.

Представь это в жсоне.

Я к тому, что они могли бы отдавать обычный жсон.

305474979_1513511:(305474979_1513510),305474979_1513512:(305474979_1513498:(86711420_1433998,86711420_1433999),305474979_1513499)

Но решили ОПТИМИЗИРОВАТЬ и вот что мы имеем.

А парсер писать необязательно, кстати

Суть враппера в том, чтобы избавить тех, кто будет им пользоваться, от необходимости бороться со всем этим говном.

Можно некоторые символы заменить и парой регексов пройтись, и получим жсон

Регексы для обертывания чисел в строки

А круглые скобки на квадратные заменить

Выглядит это просто отвратительно, но ПОКА ЧТО мне не хочется переписывать это ещё раз.

Впрочем, надо бы.

> fwd = "" > fwd_inner = "" > i = i + 1 Забыл убрать, наверное.

Так пишут вообще?))

http://joxi.ru/LmG7okLuRPd1Qm

Так пишут вообще?))

Как именно???

Ну то, что я кинул

> fwd = "" > fwd_inner = "" > i = i + 1 Забыл убрать, наверное.

Вроде там что-то ещё должно было обрабатываться, но не понадобилось и я забыл.

Это типа тот самый conn.. а потом мы можем передавать его в VkApi.Query

http://joxi.ru/LmG7okLuRPd1Qm

Токен нужен не всем методам.

Результат запроса можно кинуть в VkApi.Parser, который на основе :method_name сделает нам соответствующий tuple и вернет результаты в удобном виде

но если это не нужно - разработчик может не вызывать парсер

Если токен будет nil - мы будем его игнорировать

VK.Users.get("durov", param: "something") выглядит лучше чем new("users.get", [param: "something"], token: nil, version: nil)

Ну, передавать имя метода атомом можно, да.

Это будет легко доделать.. т.е. будет некий общий API и специализированный для конкретных команд

А специализированный просто будет вызывать общий апи)

Небольшая проблема.