Точно последните 15 минути го мъча. На всичкото отгоре безплатна е само супер орязаната му версия. Пък браузерите всичките безплатни.

Виждаш ли сега кое му е калпавото - по-трудно за подкарване. Опитай едно, опитай друго, опитай трето, докато тръгне. А WEB-а просто си върви с едно цъкане.

О ако 15 минути не е тръгнало няма да тръгне никога, просто сървър и клиент са
несъвместими.
Ако сървърът се придържа към RFB тръгва практически веднага, на по-старата (и по-добра)
версия на realVNC трябва да и се каже да ползва "all available colours" за да тръгне с 16bpp.

А че браузърите по-лесно тръгват да, то да напишеш "hello world" най-бързо става на
някакъв бейзик ако почваш от нищото - а после .

Най-смешното е че в описанието на кита е изрично написано че е правено за realVNC.

ПП: Познай кое тръгна - свалих realVNC плъгина за Chrome и... тръгна от раз. Сега гледам VNC през броузер.

После, с презрения VB6 си изкарваш хляба 13 години, нищо че преди него употребявах предимно асемблер и C. Както е тръгнало в следващите 13 ще си го изкарвам с JS/WEB програмиране. JS само по себе си е ужасно хитро нещо като език и е едно от нещата, които крепят цялата работа и вървят еднакво на всички броузери, щото си има стандарт откак е излязло. Останалите стандарти ги пишат от 100 години, а през това време всеки броузерописач се опитва да наложи някакъв свой стандарт и начин да се правят нещата. Само че, масово се ползва само това, дето работи на всичко. Микромеките с тая издънка IE са свършили такова количесто простотии, че сигурно 3/4 от бедите на WEB-а са само тяхно дело. Ама и те в 9-та и 10-та версия явно са си взели бележка че така повече не може да продължава.

Просто всяко нещо си има мястото. Не е нужно да пренебрегваме тая или оная технология. И в WEB-а и във VNC-то и в телнета няма нищо лошо. Просто WEB-а едва напоследък си изживява детските болести. Отделно по-често са ненужно тежки страниците, а не броузера. Има прекалено много писачи, свикнали на майкрософтския тертип на правене на софтуер - ръгай чушки в боба, пък те технологиите ще настигат софтуера. Има и много мангалска сволоч от всякакъв тип, работеща на половин заплата и булваща глупости, които се позакрепват да работят към 10-тото си издание.
Бе и WEB-а не е това, което беше. И смея да кажа - за добро.

Спарки, сещаш ли се за някоя книга за емебедед уеб съръврни приложения, която да е като за почти начинаещи и да има събрано всичко на едно място в нея?

Моля:
http://2.dx1.elecfans.com/dm/elec/e011_tcpiplean2.pdf

До колко е за начинаещи не знам, но поне така звучи от съдържанието.

ПП: То и аз съм начинаещ, да не мислиш че съм някакъв велик специалист. Само осъзнах че не е толкова велика трагедия. Въпроса е човек да се пречупи и да е позитивно настроен. Да остави предразсъдъците си и да види наистина ценното в цялата работа, въпреки хилядите кусури.

Мерси. Иначе ти може да не си велик специалист, ама си по-напред от мен - аз сега почвам да копая в тая област . Бъзиках с няколко кита с такива възможности (на майкрочип един, на стеларис един и т.н.) и това дето хич не ми хареса е, че имат едни конвертори, които конвертират страницата, дето си дизайнал в някакви масиви, които после контролера ги праща като получи заявка към конкретната страница и хич не ми хареса, че и най-малка промяна да направи човек и после трябва пак всичко да конвертира. Няма ли някакви по-лесни начини да се направи това и да се интегрират данните и контролите в страниците без да се ползват такива конвертори. Струва ми се много изкуствено така.

Здравейте,

има и вариант страницата да се зареди от SD карта. Ползвам ето този стек.

Разполага с FAT16, чрез WEB сървара може да се разгледа съдържанието на SD карта и съответно да се зареди HTML файл.

В страниците често се ползва UTF8 кодиране, и вероятно затова ги правят така. Точно в embedded системи не съм се човъркал достатъчно. Освен това работата е там че тия страници на всичкото отгоре се и компресират здраво. Нормален сървър я взима, компресира, и изпраща, а от другата страна броузера си я разкомпресира. В ембедед система от всякъде би било по-добре направо да се съхранява компресирана - хем заема в пъти по-малко място, хем сървъра не си играе да компресира и съответно се губи доста по-малко процесорно време и други ресурси. Принципно не би трябвало да има проблем и да се съхраняват и изпращат некомпресирани но това си зависи от конкретното изпълнение.

Няма стандартен начин. Но с някои компилатори и среди може да е значително по-лесно от други. Примерно с гцц и еклипс е супер лесно, защото еклипс може да отваря всевъзможни файлови формати, а специално за веб неща си е направо нейтив. Нямаш проблем нито с енкодинги, дори и за сорс файловете. Иначе html картинки и други ресурси в гцц може директно с objcopy да си ги "компилираш" до обектни файлове и да си ги линкваш. Ако имаш нужда от хелп как да си направиш мейкфайла свиркай. Принципно ресурсите ти стават част от проекта все едно сорс файлове. Отваряш, редактираш, компилираш и си ти....
Иначе може и в сорсовете да ги слагаш като стринг константи, ама трябва да минеш на Ц++11 щото една кавичка в стринга и проблем...
А компресията не може да я слагаш винаги. В get заяката трябва да има accept-encoding и там клиента си казва какво може. Верно съвременните браузери могат всичко, ама ние дето правим ембедед браузери не можем

Въпрос на приоритети. Ако отсрещната страна не приема компресия а ти искаш да ги съхраняваш компресирани (предполагам масова практика при малки процесори с малко памет), сървъра може да ги разархивира, което пак е по-бързо от компресирането.

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

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

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

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

ако се намеси и AJAX за динамичност, там кашата се допълва с XML (долното ниво на обмен на AJАX е XML), а за дебъгването ще трябва том круз и брус уилис да си делят клавитурата. HTML-5 като че ли се опитва да разреши повечето липси, но се набляга повече на стриминга. опасявам се, че дори след като минат детските му години, все още ще се налага използването на JS.

такаааа, тези бележки касаят HTML изобщо. за HTML в ембедед трябва много неща да се опростят, просто защото няма мускули и/или памет. затова приложенията, които си гледал, конвертират обикновен текстови файл (със стилове, примерно) в С статичен масив. защото стринговата библиотека е голяма и може да няма място във флеша за нея. или пък дори да ползваш sprintf() за да си конструираш страничката с отговора, може да няма къде да го направиш, ако имаш само 8К памет. щото като отвориш сокета за писане на отговор, трябва да го бълвнеш отведнъж.

отделен е въпроса със сигурността. при мен всеки ден се трупат около 50МБ лог вайл само с грешните заявки. 99.9% са опити за пробив, които трябва да се отиграят съответно. при това имам поне 35К адреса, които са отрязани на ниво файеруол и не стигат до апаха изобщо. да го оставих горкото ембедет недоносче в тимната ветровита нощ на вълците изобщо не е добра идея. задължително трябва да е скрито на завет и да има добри батковци да го вардят от лошите чичковци с неприлични предложения.

А защо трябва HTML5 да отменя JS? Аз не виждам и стремеж към това, а честно казано не виждам и особен смисъл.

Дедо, аз накупих разни китове, защото ми трябваше нещо наготово и да е лесно щото се захванах с това за хоби. Просто искам да изкарам разни неща от автоматизацията на къщата, за да мога да имам достъп през телефона или от някъде другаде. Та мисълта ми беше, че не ми се захваща да се боря нито с RFC-та, нито с gcc-та, нито с Еклипси. Трябва ми нещо почти готово, което само да променя по начин, който на мен ми трябва. Първо и из се замислих защо не са ги сложили на SD картата страниците и от там да ги зареждат, след като и двата кита имат SD карта, ама после пък си помислих, че може да е заради динамичните истории и, за да е по-лесно да показват данните от сензорите на платката. Стелариса даже май нямаше и конвертор или поне аз не успах да открия такъв в документацията на кита, а микрочипския конвертор пък такива ги надроби като промених страницта, че после тя взе да показва каквото се сети . Ама може и грешката да е в мен де, защото тепърва ми предстои да ги боря тия истории. Все се надявах обаче да е една идея по-лесно и по-учевидно, ама явно съм се заблуждавал май .

Кашата далеч не е само при веб-а, проблемите са на съвсем ниско ниво в програмирането. Не се създаде достатъчно прост и достатъчно гъвкав език и това е. Не като да няма идеи, просто не могат да спрат инерцията. Всичко става от сложно по-сложно. Примерно стандартната библиотека на Ц++ в момента е около 8000 файла и към 60 MB. И цялата тая боза за няколко съвсем елементарни класа. Сбъркана работа!
Все пак веб-а работи прилично, даже учудващо добре. За съжаление цената е съответноя хардуер и многото мегабайти софтуер. Това го прави недостъпен за малки ембедед системи.Хайде сървър страната някак си става. Пращаш някакви файлове и не се интересуваш много от съдържанието. Но от към клиентската страна няма как мине тоя номер. Хайде за статични странички някак си може да се парснат, даже и някакво рендване може, стига да няма буйни css-и. Но без.скриптове или джаби си остава умряла работа. Ако html-а имаше една идея повече функционалност нещата щяха да са доста по-различни. Примерно както е при WML да има понятие за променливи, събития и задачи. Дори няма език, няма възможност за писане на алгоритми. Но всъщност както са шаблоните на ц++ пак става да се описва логика. Може да се управлява трафика, може да се реагира на юзера, абе с две думи много повече спрямо html. И най-важното е че става да се вкара в ембедед система.
За съжаление или за щастие хардуерът задобря и wap-a умря, а с него и wml ще умре. Макар че покрай IoT (internet of things) точно такава технология е нужна, само дето докато се наканят да стандартизират каквото и да е, охлювът пак ще шмугне в храстите...