- From: David Lee <David.Lee@marklogic.com>
- Date: Wed, 25 Jul 2012 06:06:54 -0700
- To: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>, David Carlisle <davidc@nag.co.uk>
- CC: "public-xmlhypermedia@w3.org" <public-xmlhypermedia@w3.org>
> > I still don't think that "why" description says enough. If it > > is for the web are you expecting web browsers to implement > > this? (That seems unlikely, and if that is a requirement you > > need to get them on board sooner rather than later). > As Official Straw Person ... When I read the first chapter I was not convinced of the usefulness of the technique or the rationale. I would *like* to be convinced. Why am I not convinced? Because lately I have seen web applications (which this technology seems to be largely targeting) take a new turn. More and more (to my eye) the Markup is diminishing to almost nothing. It is being replaced *entirely* with Javascript served from the server. For example I have been playing with GWT ... this is only one technology but I see many (most?) web apps moving in this direction. The two things markup are used for are 1) A BARE BONES skeleton HTML page consisting of an empty body element ! 2) Markup in dynamically rendered HTML. ALL of the logic for determining application state is served from the server but embedded in JavaScript, JavaScript Libraries, compiled javascript etc. The problems discussed in the book of clients being out of sync with the server simply do not exist in these cases. So I will ask as a Strawman ... What types of applications are we envisioning that *in the future* (since we are still at the beginnings of discussion, naturally any results will be future apps not current ones) are we targeting for this kind of architecture? I suggest the days of client apps being written seperate from the server are numbered. The types of service API and REST services I am seeing exposed more recently are not intended to drive application state but rather are service level requests, say for example getting a list of Twitter status or a Google Map. So what kind of app are we envisioning that is 1) Written primarily in XML or HTML which is NOT deployed by said server. 2) Written independently and distributed independently from the server(s) 3) Would want the server(s) to drive application state Tangentially ... perhaps we are not talking about User to Computure applications (GUI) but rather Computer to Computer ... In which case state is not so meaningful, meaning is. ---------------------------------------- David A. Lee dlee@calldei.com http://www.xmlsh.org
Received on Wednesday, 25 July 2012 13:07:27 UTC