Rough Notes on developing a coherent document.
Who is the audience?
TOC Fodder
For all of the above I suggest we also seek input from the community and other organizations, especially OpenAjaxAlliance and relevant IETF groups.
Discussion fodder:
No easy way to tackle “Web Application Architecture” as one blob. Can’t all be defined easily. Also still something that’s in flux. Easier for the TAG to focus on issues that we know are problems that are part of the web application architecture but not the whole of it. Then we see what general guiding principles there are...
Should there be one document or a series of documents under a common umbrella?
Patterns – could be useful – how much already covered by REST architecture?
Could be value in documenting the REST architecture – define what RESTful approach is.
Javascript API vs. REST-based API within the browser – when to use which, if you’re designing an API how to make it more REST compatible. API design - “host object API.”
Taxonomies – what is a widget, what is a web application? Common vocabulary is needed. DAP discussion an exmaple – saying “use REST” meant different things to different people.
What happens at the boundaries when you use web technologies in ways it wasn’t designed to be use? There are all sorts of assumptions in HTML, etc.. which assume use of HTTP. Same problems for pulling pages from file:/ - mixed results.
Widget Web Architecture
Retrieving widgets, updating widgets, embedding widgets – all happen using HTTP. What happens to URIs inside a widget when embedded?
Current issue: Widgets installed are using widget URI scheme... When you embed a widget it might be useful for the content in the widget to have the same origin as the widget itself. Counter-view: you can use the origin of the widget archive. (e.g. wookie... But embedding spec would mean you wouldn’t need server-side wiring.)
Use of <feature> URIs to define capabilities and security - as in wdiget packaging spec.