- From: Rushforth, Peter <Peter.Rushforth@NRCan-RNCan.gc.ca>
- Date: Wed, 25 Jul 2012 14:21:11 +0000
- To: David Lee <David.Lee@marklogic.com>
- CC: "public-xmlhypermedia@w3.org" <public-xmlhypermedia@w3.org>
> 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 personally would like to see XSLT used on the client as well as the server, at least to better effect. But I'm sure you could use other technologies on XML, and I'm sure more will evolve in the future. > > 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 If an application is not driving application state, its not REST. > but rather are service level > requests, say for example getting a list of Twitter status > or a Google Map. Who says google maps are RESTful? And, really is google the only provider capable of maps? Why should maps not form part of the vocabulary of the web (XML and HTML)? > 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) See maps. > 3) Would want the server(s) to drive application state It is not just the server involved in changing application state, it is client and server together. > 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. Computer to computer interaction is still written by a human. Peter
Received on Wednesday, 25 July 2012 14:21:44 UTC