[Interest] Bringing Qt, C++ To The Web

Fri Jan 18 15:19:10 CET 2013

SOAP with attachments can get quite tricky with it's attachment headers.

No, I meant what I wrote. MIME ditched for JSON. Convert the MIME array of headers to a JSON dictionary. It is more flexible. While no one in the real world has called for it, it would eliminate the need to learn MIME (aside from mime-types). Then you can do cool things like multiplex data streams over a socket, which is what WebSockets are about. The fact that your header can now be a data structure or array thereof would allow you to transmit chunks of data for various files interleaved over the same socket. Currently, codec containers do that for media files. But what if you could control the order of the loading by instructing the servers on how to deliver the files. Like end all at once, or sequential. It would help on large-latency systems, while reducing the number of sockets needed meaning you can serve more clients on the same hardware.

But I digress. You close by pointing out that more people are adopting HTML, JS, and CSS. I'm sure that will continue until someone on some mailing list says "Hey this really sucks and I think we can do better" And then people realize that they have been doing it wrong all this time. Well, a man can hope. I fully don't expect C++ to rule the web again, if it ever did. I do expect for people to say hey, we can accomplish HTML a whole lot better as a JSON structure (I'll call JML) as {'html' : {'body': { 'this is my body.' } } } Which is garenteed to be, in current terms XHTML compliant. It gets even better if we allow limited JS in the JSON, because then you can define a style function i.e. {'html' : {'body': { ApplyStyles('H1,Red','this is my body.') } } } where H1 is defined as {'html' : {'styles' : {'H1: 'font-size': '17pt'}, 'Red' : {'font-color':'#FF0000'} then you can combine the dictionaries. You could also do conditionals and maybe even functions
 as ApplyStyles('H1+Red-RedIfPrinterMediaType()') 

The whole web (aside from backend SQL) could be a dialect of JS. If you coded your application right, none of this would matter, because you'd download the latest application library and recompile. We'd be able to rely on linked data better because everything would be XPATH-able. DOM stays, IDs stay, interop (beyond linked data) gets easier. You can still code in Python, C++, etc, your language of the day, and programmers don't have t worry about Tags. 

Bringing this discussion back to Qt, there is something that elegantly does this already. QML. Drop the idea that it
is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my JML) and you have your new, 1-technology web, that incidentally can do local apps as well. Is your mind blown yet? 

________________________________
 From: Mandeep Sandhu <mandeepsandhu.chd at gmail.com>
To: Jason H <scorp1us at yahoo.com> 
Cc: Nikos Chantziaras <realnc at gmail.com>; "interest at qt-project.org" <interest at qt-project.org> 
Sent: Friday, January 18, 2013 3:43 AM
Subject: Re: [Interest] Bringing Qt, C++ To The Web

> to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME,

MIME's a tech?!?! I thought it's just a standard used in emails and
HTTP headers to define the content type.

> SQL, .NET or Java or PHP, not to mention Linux/IIS server administration.
>
> The reason I puke is the number of standards you have to be famialr with.
> The reason I kick the puppy is this cannot be the best paradigm software
> development can have. It is an organic evolution of indepenendt technologies
> that don't come together to make a race horse, they make some kind of
> creature that has an arm, and leg, a hoof, a claw, and am mouth and exit
> hole. It's very much like a Swiss army knife - does everything but damn
> dangerous when you use all the things at once.
>
> Wt on the other hand, is C++ and takes care of all of that for you. You can
> provide a CSS, but you don't have to. It doesn't matter if tomorrow the web
> ditches HTML for XML or pure javascript, or ditches MIME headers for JSON

MIME and JSON seem quite unrelated in this context. You probably meant
XML being ditched for JSON...which is already happening. JSON
increasingly seems to be the choice for data exchange over XML (esp
for web apps).

I don't think we can wish away these new web standards - CSS3/JS/HTML5
etc. If anything more and more people are adopting them.

Just my 2 cents.

-mandeep

> ones. The toolkit will take care of it for you. Don't recode, just
> recompile. And let the toolkit take care of browser sniffing. Everything
> made hard by traditional web development is made obsolete by Wt.
>
> And yes, I would love it if Qt and Wt merged.
>
>
>
>
>
> ________________________________
> From: Nikos Chantziaras <realnc at gmail.com>
> To: interest at qt-project.org
> Sent: Thursday, January 17, 2013 11:00 AM
> Subject: Re: [Interest] Bringing Qt, C++ To The Web
>
> On 17/01/13 17:51, Konstantin Tokarev wrote:
>>
>>
>> 17.01.2013, 19:38, "Nikos Chantziaras" <realnc at gmail.com>:
>>> On 17/01/13 17:31, Pau Garcia i Quiles wrote:
>>>
>>>>  On Thu, Jan 17, 2013 at 4:28 PM, Nikos Chantziaras <realnc at gmail.com
>>>>  <mailto:realnc at gmail.com>> wrote:
>>>>
>>>>      I'm thinking more of ScummVM, DOSBox, Snes9x, etc.  Would you run
>>>> those
>>>>      on the server?  Sure you can do it.  But running on the client
>>>> instead
>>>>      has enormous benefits.  Having to download 10MB of JS is a small
>>>> price
>>>>      to pay.  If that really was such a concern, YouTube wouldn't bee
>>>> that
>>>>      popular.
>>>>
>>>>  And here we are finally, back to the thin client vs fat client debate
>>>>  :-) It always happens when webapps are involved.
>>>
>>> Not when you don't have a server, just dump web-space ;-)
>>>
>>> Google had the right idea with NaCL, but since other browsers don't plan
>>> to support it, we're stuck with JS.
>>
>> 'Stuck' is keyword here, because JS from Emcscripten is not going to run
>> as fast
>> as NaCl or even close to it. However, anyone can implement NaCl for
>> Firefox
>> and other browser via NPAPI plugin.
>
> If the browsers don't come with it out of the box, then people will have
> to download that plugin.  But if they have to download the plugin, then
> they might as well download the native executable application instead.
> The point it to be able to give a URL and have it just work without
> users having to manually download anything.  Pretty much what web
> deployment is about.
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130118/5d2eb35b/attachment.html>