Ну это, мне кажется, перебор

Сделай тогда из своего json-а строку и все

тогда нельзя будет вложения проверять, типа возникло событие с тегом {"region": "ru"} и подписка вида {"key": {"region": "ru"}}, простая проверка на вхождение покажет, что подписка подходит, а на самом деле нет. поэтому надо сериализовать в такой массив ["key!string.region.ru"]. еще пример {"b":"1","c":["1","2","3"]} => ["b!string.1", "c!array.1", "c!array.2", "c!array.3"]

Вы лучше задумайтесь, нужно ли вам вложение

Плоскими тегами будет проще

Да и быстрее

поздно задумываться, уже почти готово. ну и никто не запрещает пользоваться плоскими, вложеность лишь доп. возможность

По перфоменсу ударит

У вас и так логика не тривиальная...

будем оптимизировать по мере необходимости. это вы еще не видели других возможностей) есть еще забавные идеи

Оно то понятно. Я прежде всего на работе задаю вопрос: на сколько часто мы будем использовать подобный функционал?

Если логика сложная - оно будет и дольше работать и сложнее поддерживать

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

Иногда проще отказаться от чего-то подобного в пользу производительности и простоты.

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

Вы эту вложенность сами, предварительно, можете разворачивать

ну собственно сериализатор и разворачивает ее в плоский массив строк

сериализовать нужно только один раз при подписки или инвоке события

по разу на метод в общем

Инвок может быть весьма часто

А потом ещё поиск нужных подписчиков

А как передается событие с тегами?

насчет поиска тоже есть идея, как не делать перебор, а искать по словарю. и для этого тоже нужно сериализовать, как раз

По факту это просто событие, в параметр которого передается или this или что-то подобное

У вас передается 2 параметра?

при инвоке?

Да

насчет поиска тоже есть идея, как не делать перебор, а искать по словарю. и для этого тоже нужно сериализовать, как раз

Не представляю себе эту реализацию

массив tags, словарь data передается

Лично я вижу только перебор какого-то списка и подписчиков и сравнение его тегов с событийными

ну и указывается, что action=invoke

Что за словарь?

просто словарь с любыми дополнительными данными

void*

?

Лично я вижу только перебор какого-то списка и подписчиков и сравнение его тегов с событийными

если получится реализовать, как видится, то потом может обьясню, сложно это словами описать сейчас, но идея визуально, если рисовать то простая

ну как, любой джейсон может быть

А вы завязываетесь на Джейсон?

вообще это опенсорс штука, но пока рано показывать кому-то

А если я хочу бросить событие и передать туда объект класса Test

да, привыкли с ним работать

тут надо указать, что обмен по вебсокетам происходит основной, еще есть задумка по http дублировать некоторые методы

сейчас есть клиент на js, еще на питоне будет

Аааа

Я думал это в контексте одного приложения

клиент на D, как раз в планах нету, что странно) надо добавить

Ну, интересно.

В сторону Рабита не смотрели?

Или это и была конечная цель - написать нечто подобное?)

смотрели, но хочется, что-то маленькое, простое и быстрое

А чем он велик?

что бы в итоге один бинарник, запустил его и сервис готов

Подняли образ из докера и все работает

Не понравилось - грохнули...

Иными словами - набор этих тегов и есть имя события.

Верно?

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

да

Была у меня подобная затея)

Но не с такой сложной логикой

Тут вы, конечно, не хило замахнулись!

Что ещё планируется?

Из функционала

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

метод request, это тот же invoke, но клиент желает получить ответ от подписчика. в свою очередь подписчик, если решит ответить, то шлет метод chat, который позволяет им потом общаться, пока кто-то не пошлет последний chat с параметром finish

Мне нравится, как это реализовано в рабите:

Ты просто создаёшь дополнительную очередь, а в сообщении указываешь имя этой очереди, в которую нужно залить ответ

ERROR: S client not available

Вот и все...

Просто и гениально

это конечно да, но не зря же там документация огромная, это только базовая штука

Я о том, почему бы вам также не сделать?

Я о том, почему бы вам также не сделать?

ну это можно будет сделать. указать один тег строкой и все, но можно будет сделать и намного больше

как в D сделать thread safe очередь, что бы с разных потоков с ней работать? достаточно так? DList!string queue; // add queue.insertFront(data); // pop auto data=queue.back(); queue.removeBack();

как в D сделать thread safe очередь, что бы с разных потоков с ней работать? достаточно так? DList!string queue; // add queue.insertFront(data); // pop auto data=queue.back(); queue.removeBack();

Посмотри objdump-ом, падает ли она в tls

То есть в секцию .tdata

попробую сейчас

Бред, она же динамически у тебя собирается, да?

честно говоря не знаю, но вообще такой make dmd -c $(SOURCES) -odtmp $(D_FLAGS) dmd tmp/*.o -of${TARGET} $(LIBS)

Нет, я не про сборку проекта

Я про то, как ты дополняешь очередь элементами

а, ну да, конечно

я вообще пытался вот так сделать как-то synchronized class SocksQueue { private DList!string _queue; public void f(string data){ _queue.insertFront(data); } } но ошибку выдает Error: template std.container.dlist.DList!string.DList.insertFront cannot deduce function from argument types !()(string) shared, candidates are:

Я думаю что ты делаешь вполне правильно, так и надо.

как в D сделать thread safe очередь, что бы с разных потоков с ней работать? достаточно так? DList!string queue; // add queue.insertFront(data); // pop auto data=queue.back(); queue.removeBack();

вот так?

Я про концептуальность

Делаешь synchronized класс очереди, и тогда каждый тред заходит в метод pop() эксклюзивно, никаких гонок не будет.

Ну а то что ошибка там выскакивает - да надо просто ее порешать )

понял, значит надо технические моменты порешать

вообще можно просто в скоупе очередь определить synchronized { DList!string _queue; } но хотелось ввиде класа это сделать, что бы методы определить для работы с очередью, а не напрямую работать. еще посмотрю

Лучше класс, ведь иначе у тебя работа с этой очередью будет неатомарной

Получить последний элемент и удалить элемент из очереди это две операции насколько я понимаю

Получить последний элемент и удалить элемент из очереди это две операции насколько я понимаю

да. ну и вообще лучше класс, но с ним пока не вышло что-то

none of the overloads of 'removeBack' are callable using a shared object т.е. методы dlist'а не хотят работать с шаред объектами

А зачем именно Длист?

Чего не простой массив?

удаление быстрое

Кстати можно попробовать из std.container массив использовать

Кстати можно попробовать из std.container массив использовать

все так же, методы контейнера не умеют работать с shared переменными

хм