Karl Dubost (to www-archive) :
Web 2.0 is really about putting applications into the Web.
I wish we just do the opposite, (Web Architecture 101 + REST)
putting the Web into applications,
aka use HTTP and URIs for webifying every applications.
I think Karl's on the nail here. Ok, so the regular browser is a highly capable UI container, but it's pretty generic (or perhaps rather HTML-doc specific), so optimising for specific tasks or domains can be hard work. On the other hand, existing applications tend to be already optimised for their purpose, whether they're desktop UI things or headless processing apps. So lead Mohammed to the mountain.
Seems to me like there's a strong (overlapping) parallel with the RDF/database situation. While you can reengineer DB-based apps to use triplestores, for existing apps it will usually make more sense to bridge between RDBMS and the Semantic Web on the fly (using tools like D2RQ). Similarly it'll usually be easier to get rich applications on the web bus by HTTP-enabling them, rather than completely reengineering to run in the browser.
What does this mean in practice? Embedding a HTTP server in every app would be one approach, but there is the snag of port conflicts. This suggests it would be better to have a single HTTP server running on a given machine, with system-level hooks from applications *. Either way, every resource of interest inside the app in question would be identified by a URI and be addressible.
A HTTP client in every app. This avoid the port issue, but makes
for an interesting situation when you want to get data out of the
app, the operation being initiated outside. In such a case one
solution would be to have an external proxy that could be polled by
the client for requests, with the client pushing data to resources
managed by the proxy.
Messaging via Atom?
Dunno, other approaches?
* this reminded me of some noodling I did a while back, looking at using the hierarchical filesystem as a triplestore (with files corresponding to resources, predicates somehow mapped into the fs structure). One of the System One guys followed through a bit with that, not sure what happened. But even this wouldn't be necessary - most web servers can publish & manipulate files, most applications can address/manipulate files. Technically the hard parts seem to have been solved. Putting together conventions for sharing the server, and having app developers following those conventions is another matter...@en