subject: Метадата
28.02.2019 14:27
Difrex (dynamic,1) => C0oZ2QgNoKfO3kFiAW
>Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Вот это еще не особо нравится.
Со стороны клиента мне это видится так:
====
+--------------+
| |
| IDEC Client |
+------>| |<------+
| +--------------+ |
| |
xdata tag message
| data
| |
| v
+-+-------------+ +-----------------+
| /u/m/gkC... | | /x/d/gkC... |
| | | |
+---------------+ +-----------------+
====
Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.
--------------------------------------------------------------------------------
subject: Re: Метадата
28.02.2019 14:47
Andrew Lobanov (tavern,1) => VJPNtsUz2RhjJUXPAqZs
>> Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Difrex> Вот это еще не особо нравится.
Difrex> Со стороны клиента мне это видится так:
Difrex> ====
Difrex> +--------------+
Difrex> | |
Difrex> | IDEC Client |
Difrex> +------>| |<------+
Difrex> | +--------------+ |
Difrex> | |
Difrex> xdata tag message
Difrex> | data
Difrex> | |
Difrex> | v
Difrex> +-+-------------+ +-----------------+
Difrex> | /u/m/gkC... | | /x/d/gkC... |
Difrex> | | | |
Difrex> +---------------+ +-----------------+
Difrex> ====
Difrex> Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
Difrex> один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.
Зачем третий запрос? Клиент видит тэг, запрашивает все аттачи по этому тегу. Ему приходят они. В верхней квоте ни слова про третий запрос нет. И на схеме у тебя его нет.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Метадата
01.03.2019 10:41
Difrex (dynamic,1) => mPHaeAe0SQbTC4ANmdHT
>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>> Вот это не нравится. А если я не хочу все аттачи тянуть?
> Тогда просто игнорируешь тег и всё.
Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
--------------------------------------------------------------------------------
subject: Re: Метадата
01.03.2019 11:57
Andrew Lobanov (tavern,1) => o9M1OtGvA8rsH0UjwWTI
>>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>>> Вот это не нравится. А если я не хочу все аттачи тянуть?
>> Тогда просто игнорируешь тег и всё.
Difrex> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Метадата
01.03.2019 18:14
Difrex (dynamic,1) => ogfKFLLBZGSvZAgK75nX
>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
>Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.
Но что-то делать с этим точно надо :)
--------------------------------------------------------------------------------
subject: Re: Метадата
01.03.2019 18:27
Peter (syscall,1) => ogfKFLLBZGSvZAgK75nX
Идея была все-таки вот в чем.
С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.
Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Ну как в современных мессенжерах. :)
А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.
--------------------------------------------------------------------------------
subject: Re: Метадата
02.03.2019 20:02
Andrew Lobanov (tavern,1) => xqHLvtt8AJyqBymBPA39
Peter> Идея была все-таки вот в чем.
Peter> С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Peter> Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.
Peter> Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Peter> Ну как в современных мессенжерах. :)
Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов. В итоге мы имеем повсеместно имеем всё равно те же файлы, но только спрятанные глубоко и неудобно.
Peter> А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.
Ну тут да. Можно подумать как и что пропускать. Можно метаданные передавать ещё к каждому блобу.
--------------------------------------------------------------------------------
subject: Re: Метадата
02.03.2019 23:17
Peter (syscall,1) => Jzf2nfTWwJuZDFU4di84
> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.
Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.
--------------------------------------------------------------------------------
subject: Re: Метадата
03.03.2019 08:25
Andrew Lobanov (tavern,1) => le3Gza9rtjg2aYluzYQM
>> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.
Peter> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.
Вообще, я примерно так и думаю.
Например:
====
image:<filename>:<base64>
audio:<filename>:<base64>
====
А желание не пропустить информацию, ИМХО, противоречит самой цели секты.
--------------------------------------------------------------------------------