Хм, нищо общо. По-скоро "нещо" (размито) дето предоставя услуги - PaaS, SaaS или някакви такива. Може нищо да не съхранява и пак ще е облак. И определено вече рядко се свързва с SQL...


Ако тръгнем да го модифицираме можеш спокойно да ни заплюеш публично. Модификации може да има ако сме в групата дето движи стандарта - е, не сме там. А и няма за какво да го правим - не мисля че трябва да му набутаме SQL или база данни, което за някой хора май изглежда като страхотна идея.
Между другото, като ползваш SQL модифицираш ли го, подобряваш ли го? Налага ли ти се да измисляш SELECT_EX че да можеш да "адднеш еди какво си устройство"?
Как виждаш този аспект на добавяне на устройство - струва ми се че приемаш че ще трябва да се рови по "cloud"-а за да се добави следващия модел устройство, които имал примерно по-голям дисплей или е добавил файлова система?

Казах го в предишен пост - ценното на MQTT и на всеки свестен стандарт е че покрива един определен аспект - туй се казва "single responsibility" принцип. Това се пояснява като "single reason for modification" - само по една причина може да се наложи да го променяш, т.е. само ако излезе нова версия на MQTT стандарта ще се сменя. Неща като бази данни е хубаво да липсват от спецификацията че става мазало.

Съвсем конструктивно, вземи поясни един-два недостатъка на MQTT че да вземем да потърсим или направим нещо по-добро. Има една щуротия - Redis, което е no-sql база с поддръжка на publish-subscribe. Щях да питам palavrov за нея и как е спрямо mongodb, но за момента не съм на това ниво и няма нужда да губя и неговото време.
https://redis.io/topics/data-types-intro
Съхранява данни не като таблици и релации, а като "нормални" програмистки данни - списък, сет, подреден сет, хеш и т.н. Класифицира се като отдалечен речник от key-value тип.

Другото което имам "напреко" обожествяването на SQL или друга база - в случай споменах че говорим за нещо което е SCADA или HMI които представят някакви устройства (обекти) с техните данни, събития и методи. Обръщам внимание на "ТЕХНИТЕ" - данните са в устройствата, т.е. всяко дуплициране в измислена "локална", "глобална" или каква да е изкуствено. Има логика да се кешират данните за производителност - в някой случаи, има логика да се съхранява лог от данните - в някой случаи, на определени данни, с конфигурируеми времена, компресии и т.н. Т.е. да ги вкарам в SQL база за да ги вадя после с заявки е ... да го кажем по-леко - неефективно, забавящо, предполагащо възможност за грешки в смисъл на неактуалност, конфликти между паралелни клиенти и много други.

В архитектурата която ми рисувате с Miro слагате базата на сървъра в средата. Не, там е речника които прави достъпа до услугите на наличните устройства. База може да има опционално ако някой иска да съхранява нещо. Това нещо (параметър, аларма) може да се ползва отделно. Т.е. ако в конфигурацията на елемента "температура на охлаждащата течност" искам ще активирам логване или следене за лимити, или каквото друго реша. Но няма логика да съм набутал 14000 параметъра в базата за да мога после да тегля един. Е, ако някой иска може да го направи, негов избор, но на забавянето ще се "радва" само той, а не всичките клиенти.

Аз те питах, но да питам пак - картинката "устройства-сървър-клиенти" ли е ?
И ако да, сървърът по средата за украса ли е?

протокола не съм го барал...да кажем, че съм модифицирал Москито с DLL плъгини, които следват логика за "сотриране" на данни и съответен директен запис в база. Узер шаренията(HMI) чете базата и визуализира....става и на node, но производителноста на javascript е да кажем минимум 10 ПЪТИ по-тромава. A като напускаш отделни процеси към брокера хептен ще се омоташ, но както и да е
Пак ви казвам - сложеш ли с Java, Python... в индустрия ще страдаш много... НО, ще разбереш когато се опариш

в случая с MQTT не е сървър а брокер за разпределение на съобщения

Не ви разбирам теологичния спор тука - node е инструмент а не някаква архитектура или парадигма или пък протокол. Просто удобен инструмент който ти позволява да градиш каквото ти требе. Все едно със SQL или PHP не могат да се правят кофти проекти та ...

Спора е че "модерното" наименование на ОБЛАК и функциите му приложено в индустрия със скрикпове от GitHub е не приложимо на този етап

Аз пък не разбирам архитектурата... все пак темата уж беше за архитектури, а така и не стана ясно каква е, освен че е някаква свързана с облаци... И при неясна архитектура се обсъждат инструменти, демек после по копче ще се шие балтона

Тц - спора от бая време е заради самия спор ... Гичо имаше въпрос - разбрахме се с неколко реплики ... а сега вече мерим чий е по голям и хубав и на кой му е грозен и крив ...

ами кажете че темата е приключена тогава и да не са хабим повече!

Те това се прави лесно с node и доста по трудоемко с други езици и фрамеворки.

Еееее ... една друга тема откъде тръгна па накрая стигна до градинарство - нали трябва да си чешем някъде езиците и да си мерим там каквото си мерим

Абе не знам... не ща да спорим. Той по принцип Гичо като си науми нещо не се отказва, така че освен да му пожелаем по-малко мотики по пътя друго няма

А иначе за протокола, това не са конкретни изисквания, щото всяка една система почва с подобни пожелания - да е отворена, да се развива лесно, бля, бля....
Да кажеш че това се прави най-лесно с node... позволи ми да не се съглася с теб и да си стиснем ръцете, нали всеки имаше право на грешно мнение

Да, трите части са там. Как са deploy-нати е друг въпрос - на едно, две или 3 устройства (че и повече). Ако имаш предвид че като пусна две от тях, или направо и трите, на едно PC нямам сървър, не съм съгласен.
Каква ти е логиката на "украсата"? Без него не работи системата - там ми е бекенда.
Минималните цели са няколко:
- преодоляване на firewall-и
- централизирано репозитори за достъп до група от устройства и/или услуги (server-side приложения които обработват или командват нещо - например firmware update на едно или много устройства)
- конфигуриране на разни неща - правата за достъп, връзки към други услуги (сървъри) и подобни, ако щеш и shell да се обновява фронтенд софтуера
- място за разширяване на функционалността с нови приложения - примерно превод от един към друг протокол за достъп
- осигуряване на този достъп за разширение - когато клиента иска от централата си в София да следи (програмно, не машинописка-пред-компютър) завода в Пичковци през http или каквото там SAP-а му или другите системи искат
- опционално - съхранение на история на данните, анализ, нотификации към tweeter, фейса, бузата и каквото там е модерно

Повечето от тия неща са опция - разбирай могат да тичат другаде, да се плащат отделно и т.н.

@Wizard - представи си че и node.js дава тази възможност - да разширяваш брокера. Само че не го прави "в DLL" (нa виндовс ли ги пускаш тия неща?) и е платформено независимо. Ето за справка:
http://www.mosca.io/

Само че да слагаш плъгин (да "бараш") брокера за да добавиш тия сортирания и база - извинявай, е тотално грешна постановка. Това може и да сработи за тнтм модела - дай да сложим едно пц от итр-а секонд хенд и да му пуснем едно нелегално уиндосче - за един конкретен клиент, но най-малкото не пасва на логиката за евтин хостинг на PHP нейде... Как ще разделиш нещата (базата, обработката (бизнес логиката)) че да ги сложиш на оптималните места? Как ще направиш load balancing или failover с твоя "пачнат" DLL? Как даваш достъп на трета фирма да направи обработки на данните? Как ще смениш безболезнено брокера - щото някой е пуснал друг дето има "20 ПЪТИ" по-висока производителност, или друго което ти трябва?
Ако това е опита ти с MQTT мисля че се сещам защо не се е получило - трябвало е преди да почнеш да го пренаписваш да разбереш как работи и каква му е идеята.

А за производителност - не мога да споря преди да съм пробвал, за момента съм чел и гледал подобни неща и измерени времена за реакция и т.н. Има и други аспекти като време за направа на едно приложение, усилия за поддържане и администриране. Ако това "10 ПЪТИ" не е изсмукано от пръстите ще е полезна информация - казваш че си правил същото на javascript с node.js и е работили 10 пъти по-бавно ли?
Ако те интересува разгледай кое как се скалира. Представи си че в някой случаи е бонус да можеш да подкараш нещо на сървър някъде, какъвто не можеш да си позволиш при теб в момента?
Терминът "плъгин" съществува да покаже нещо, което може да разшири функционалността на друго нещо (да я допълни обикновено). Архитектурата на node.js няма термин за плъгин - защото цялата архитектура там е направена да позволи такова разширение -т.е. всяко едно приложение (пакет) може да се ползва програмно и да се закачи към друго.

MQTT е брокер - нещо дето чака и дава услуга на други. Това се превежда като сървър. Ако имаш предвид че не е квадратна метална кутия с няколко мрежови дупки - прав си, не е. Не е и http сървър, прав си. Ма айде да не съм твърдял такива неща. Представи си че наричаме "сървър" нещо дето може да е някъде в мрежата и да ни върши някаква работа на нас, простите клиенти. Е такова е. Или е нещо дето може да е "хостнато" някъде и да си го купиш/вземеш да ползваш.

@palavrov - аз не споря за инструмента, надявам се колегите да са разбрали че не това е важното; дискусията вече се върти около архитектура и концепция

Едит: ей, евала, толкова активна тема - не мога да пусна едно съобщение без някой да е писал - радвам се!

Пак едит: спорът беше за архитектура и завъртя към инструмент, аз искам да го завърна към архитектура. Ако има по-добри инструменти няма да споря. Макар че за node.js са разработени и налични доста решения които показват определени архитектури. Това е нещото което е разликата между теория и практика. Или наличен know how който не обичам да пренебрегвам.

Хайде сега да спрем с абстрактните понятия и дайте примери с реални устройства какво може да прави този "облак"

Пример:
Някъде има машини - например шприц. Това ще го водим embedded устройство. Приемаме че се намира в цех - бившо ТКЗС в близко до града село.
Има един частник, който знае че работниците го цакат и претоварват примерно машината за да изкарат надника.
Сеща се че у тях има лаптоп, комшийката има таблет а той естествено разнася смартфон. Сеща се че който му е правил или продал машината може да му помогне и е готов да забави покупката на новата X5 за да си докара рахатлък.
Задачката в опростен вид е от всяко от тези устройства той да може да наблюдава няколко стойности - позициите на оси, скорости, температура на охлаждаща течност, статус на крайни изключватели.
Данните идват от "устройството" и ние имаме достъп до тях - дали по мрежов протокол, дали като API call локално - няма голямо значение.
Интернет идва през калифорнийка на покрива на ТКЗС-то от доставчик от селски тип, който цепи един ADSL в съседното село и го пуска на 10-тина "земеделци".
Интернет до клиентските устройства може да идва през adsl, кабеларка, мобилен, сателитен, и т.н.
Целта е да напишем код за машината и умните устройства които да си говорят и да изпълняват заданието. Да кажем че човека иска да вижда "температура" на нещо си на екрана. По-точно моментната температура, в градуси по Целзий.
Без централна точка ще е малко кофти заради частните адреси за NAT, това е ясно. Отделно искаме и трите (лаптоп, десктоп и телефон) да могат да гледат едновременно.

Моето виждане е:
- правим централна точка (сървър, брокер, облак, няма да се втеляваме за името) - съобразяваме се с кешовицата на клиента - евтин MQTT брокер примерно (има безплатни планове с ограничен трафик и брой клиенти) или клъстър за 100000 едновременни клиента
= защо mqtt - публикуването на данните става веднъж - при промяна или с inhibit време ако често се сменя (Inhibit се прави в кода който чете от някъде и публикува към Mqtt, не е част от функционалността на брокера)
= данните които прехвърляме са много по-малко отколкото при http get/post примерно
= еднократно публикувани стигат и са достъпни за N клиента (и трите клиентски устройства)

- закачаме машинарията да публикува данни (и абонира за контрол, но това не го гледаме за сега)
- нагласяме frontend-а да ползва данни от този брокер и акаунт
Опции за фронтенда много - от телефона приложението може да се закача директно към брокера за да получава промените на температурата. Това решение пести от трафик но изисква да има специализирано приложение (например андроидско apk).
Може и да отваря страничка с html5 който да прави browser-side обработка за да може да рисува 3д. В този случай след mqtt брокера (или до него) има http сървър който да достави кода на страничката и да организира достъпа от AJAX заявки към MQTT-то, или покрай него директно към MQTT брокера ако той поддържа websockets.

След година бизнеса на ТКЗС-то се разраства и заема всичките обори. Човекът си наема "хакерче" за IT и го натоварва да направи "сайт" на фирмата. Онзи е разтропан и му предлага да правят онлайн поръчки, като по номер на поръчката клиента да може да зяпа къде и как се прави поръчката му - нещо като SCADA.
За да си направи страничката IT-то ни звъни (с кешовица под ръка) и пита може ли да стане - даваме му достъп до някой от нивата - дали до MQTT брокера или до следващи нива във фронтенд-а според зависи (пак от кешовицата). Онзи закача неговия сървър да получава данните и по телевизията дават как "един българин е направил уникално изобретение".