Re: ACTION-434: Some notes on organizing discussion on WebApps architecture

On Oct 14, 2010, at 5:08 PM, Noah Mendelsohn wrote:

> Larry Masinter writes:
> 
> > Web Applications have extended the concept of "resource" beyond the original meaning
> > to something that is really beyond what was identified before -- it isn't just
> > "a resource" but "an application resource in an identified state".
> 
> For some applications, yes, but I think there are interesting counterexamples including...

> 
> > So a map location of Google Maps is "The Google Maps
> > application, in a state where the route from my
> > house to the meeting is highlighted".
> 
> I think this misses the fact that Google Maps can be viewed as a giant, flexible interactive document, something that's less true of some other Web applications.  Indeed, I prefer to view Google Maps that way.  For most practical purposes [1]is very similar in character to [2].  In both cases, when the user follows the link, the typical result is to wind up in the browser, looking at a portion of a much larger document: in case 1, it's the map of the world, at a certain level of detail and zoom, centered on W3C; in case 2, it's the TAG's architecture document, at a certain level of zoom, focused on the section on identification.

I agree largely with this. But, I do think there is a middle path, where the route representation arrives at the user-agent with a default (and unspecified) level of zoom (or default centred in some place) but where the defaults can be changed by supplying additional parameters (zoom=150% or centre=42.5,40.16, say) - I actually think these parameters are not about the route itself, but do impact how the representation of the route is displayed by the application. Do you think the "zoom" of a map, or the point upon which the map is centred are part of the route resource?

I guess I would suggest at this structure:

i) A route is a set of co-ordinate points
ii) One representation of a route is as a snippet of a graphical map, where lines are drawn between the co-ordinate points
iii) If the Web application happens to be a "map browser", one might control the behaviour of the map browser in displaying a route by centering it on a particular point, and having the map zoomed 

That says to me that we have 3 resources as part of the Web application - a route, a map, and a configurable map browser application. 

> 
> In both cases, browser interaction can be used to change the view of the document, to move to different portions, etc.  Of course, the implementations are radically different:  [2] uses Javascript hardly at all, and on the client, [1] depends on it heavily.
> 
> Still, I think it's very useful to focus on the similarities, and to encourage them for applications where that makes sense.  So, I see a taxonomy of Web resources that's more like:
> 
> * Document-like:  links identify either the document as a whole, or some perspective on, position in or fragment of the document.  Typically, user agents will, with or without the aid of Javascript, provide for manipulation of the document, moving within it, etc.  Both [1] and [2] fall into this class.
> 
> * Non-document application:  let's say you implement the dashboard of some future car using HTML and Javascript, with the accelerator and brake pedal as input devices that Javascript can "read", and with APIs that Javascript can use to actually control the engine and the breaks.  This is a better example of the sort of application you describe:  links to this one really will be to the state of the application (no throttle, brakes applied hard), and not to a document.
> 
> In short, I think the referent of the URI should depend on the nature of the information or application being manipulated, and not necessarily on its implementation using techniques like AJAX.

I agree with this statement, but I believe that Web applications may also be combinations of the types you describe above.

Regards,

- johnk

> 
> Noah
> 
> [1] http://local.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=w3c,+cambridge,+ma&sll=37.0625,-95.677068&sspn=47.215051,114.169922&ie=UTF8&hq=w3c,&hnear=Cambridge,+Middlesex,+Massachusetts&z=14&iwloc=A
> [2] http://www.w3.org/TR/webarch/#interaction
> 
> On 10/14/2010 2:54 PM, Larry Masinter wrote:
>> Web Applications have extended the concept of "resource" beyond the original meaning
>> to something that is really beyond what was identified before -- it isn't just
>> "a resource" but "an application resource in an identified state".  So a map location
>> of Google Maps is "The Google Maps application, in a state where the route from my
>> house to the meeting is highlighted".
>> 
>> Perhaps it might be "best practice" to use the fragment identifier and/or the query
>> parameters of a URI to be the way in which the state of the application is identified,
>> with the URI of the application entry point itself ("Google maps entry") obtainable
>> by stripping the fragment and query.
>> 
>> The design problem is not so much "the problem of identifying resources" as it is
>> "the problem of designing application resources so that meaningful perspectives
>> of application state can be identified".
>> 
>> For example, the maps application, when I am using it, has many parts of its
>> internal state, not only  sharable information about the route (source, destination,
>> mode of transportation, perhaps estimated start time of travel), but also information
>> that should not be shared, for example, my identity and the authenticity of the
>> credentials I've used to log in. A designer of a map application has to decide
>> which of those elements of application state are to be retained and communicated
>> in the URI itself, and which are best left to cookies or other elements of storage.
>> 
>> The design problem is made more difficult because of the requirements of privacy
>> and security, for example, since, as we've reviewed before, URIs themselves should
>> not be designed to carry information that should not be publicly shared.
>> 
>> Larry
>> --
>> http://larry.masinter.net
>> 
>> -----Original Message-----
>> From: John Kemp [mailto:john@jkemp.net]
>> Sent: Thursday, October 14, 2010 11:34 AM
>> To: Larry Masinter
>> Cc: Appelquist, Daniel, VF-Group; jar@creativecommons.org; www-tag@w3.org
>> Subject: Re: ACTION-434: Some notes on organizing discussion on WebApps architecture
>> 
>> On Oct 13, 2010, at 9:57 AM, Larry Masinter wrote:
>> 
>>> A perspective on deep linking into applications:
>>> 
>>> When you organize information to be made available as "hypertext", you actually have to
>>> figure out how to break it up, lay it out, and make it available in a way in which it
>>> can actually be linked to. It's a design problem.
>> 
>> The problem of identifying "resources" - no?
>> 
>>> 
>>> This is also the case with web applications, not just web text.
>>> 
>>> It seems like we are asking the question, for arbitrary applications, "how can
>>> I link into a particular application state." But applications actually have to
>>> be designed so that the application state is linkable.
>> 
>> Such that "application state" is exposed as Web resources, sometimes, but not always, with associated URIs (in the case that some Javascript API is called, for example)?
>> 
>>> 
>>> Many web applications haven't been designed in a way that the application state
>>> is restorable, so that the URL of the "application state" at any particular
>>> time *isn't* showing something in the address bar that can be saved, restored
>>> later, etc. Sometimes remembering application state doesn't actually make much
>>> sense.
>> 
>> Well, it perhaps makes sense locally for that instance of the application, but exposing it for others might not make any sense.
>> 
>> [...]
>> 
>> Cheers,
>> 
>> - johnk
>> 
>>> 
>>> Larry
>>> --
>>> http://larry.masinter.net
>>> 
>>> -----Original Message-----
>>> From: Appelquist, Daniel, VF-Group [mailto:Daniel.Appelquist@vodafone.com]
>>> Sent: Wednesday, October 13, 2010 3:45 AM
>>> To: Larry Masinter; john@jkemp.net; jar@creativecommons.org
>>> Cc: www-tag@w3.org
>>> Subject: Re: ACTION-434: Some notes on organizing discussion on WebApps architecture
>>> 
>>> Hi larry - very much agree with the below. I think another key issue which you allude to is that of linking between web applications. One of the "things that is broken" right now with the increasing use of applications and web applications on mobile devices is consistent linking / bookmarkability. In an mobile app, you are contained within the walls of this app for the most part and your navigation choices are limited to what the app can offer you. One differentiator of the Web vs stand-alone Apps should be to allow webapps to (deep) link to other webapps and to allow these (deep) links to be bookmarked.
>>> 
>>> Technologies like appcache and widgets muddy the waters a bit by making it less clear how to link into a webapp. Perhaps this could become the the basis of a TAG finding on "webapp linking best practice"? However I think we would need to seek input from (eg) the webapp working group on this point.
>>> 
>>> Dan
>>> --
>>> Daniel Appelquist
>>> Vodafone Group Research&  Development
>>> Mobile: +44 7748 111635
>>> daniel.appelquist@vodafone.com
>>> 
>>> ----- Original Message -----
>>> From: Larry Masinter<masinter@adobe.com>
>>> To: John Kemp<john@jkemp.net>; Jonathan Rees<jar@creativecommons.org>
>>> Cc: Appelquist, Daniel, VF-Group; tag<www-tag@w3.org>
>>> Sent: Wed Oct 13 01:19:17 2010
>>> Subject: RE: ACTION-434: Some notes on organizing discussion on WebApps architecture
>>> 
>>> The "global hypertext network" has become a "global hyperlinked application
>>> network".
>>> 
>>> Originally, when we thought of hyperlinking "text", we might consider
>>> linking from a book or article to its references.
>>> 
>>> But now, we're linking from an application that allows users
>>> to collaborate about products, services, travel, into applications
>>> that let you buy products, pay for them, reserve at hotels, etc.
>>> 
>>> So "hypertext" has become "hypermedia" has become "hyperapplication".
>>> 
>>> Before the web, "hypertext" was thought of as a closed system where
>>> the whole hypertext corpus came from a single source and hyperlinking
>>> was coordinated. The "web" opened this up so that different publishers
>>> of information could link to each other readily.
>>> 
>>> The "web application" infrastructure allows applications to link
>>> to each other, and we're still at the infancy of this space -- there
>>> are many practices, and very little agreement on what constitutes
>>> "best practice".
>>> 
>>> I think an "architecture" for web applications would identify what the
>>> issues are for reliable interoperability among disparate applications,
>>> examine some of the use cases, issues and solutions.  Issues around
>>> security, privacy, reliability, extensibility, upgrading, saving state,
>>> and so forth ...
>>> 
>>> Larry
>>> --
>>> http://larry.masinter.net
>>> 
>>> 
>>> -----Original Message-----
>>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of John Kemp
>>> Sent: Tuesday, October 12, 2010 11:07 AM
>>> To: Jonathan Rees
>>> Cc: Appelquist, Daniel, VF-Group; tag
>>> Subject: Re: ACTION-434: Some notes on organizing discussion on WebApps architecture
>>> 
>>> Hi Jonathan,
>>> 
>>> On Oct 12, 2010, at 10:26 AM, Jonathan Rees wrote:
>>> 
>>>> High-level rant, the result of my puzzling over the nature of our
>>>> applications work. Sorry if this is low content, but I wanted to post
>>>> it before the F2F.
>>> 
>>> Thanks for posting, as this question has been also puzzling me for a few days as I work on my own Web Apps-related actions. I found this very helpful in motivating my thinking.
>>> 
>>>> 
>>>> One thing that makes the "web architecture" design successful is that
>>>> it is an architecture *of* something, namely a global hypertext
>>>> network. That characterization sets the scope nicely and sets terms
>>>> under which it can be evaluated and judged.
>>>> 
>>>> I think it would help a lot if we knew, in this round of work, what
>>>> sort of thing was supposed to have architecture. Are we talking about
>>>> an application-enriched hypertext network? A rich client/server
>>>> application platform?  A globally distributed computing platform? I
>>>> don't know, but I have a feeling that if we don't set some boundary
>>>> we'll spend a lot of time wandering around unproductively. If we're
>>>> going to boil the ocean, I at least want to know *which* ocean.
>>>> 
>>>> As we look beyond "global hypertext network" it might be helpful to
>>>> look at historical precedents of platform scope expansion. For
>>>> example, Unix was a beautiful and successful operating system for
>>>> PDP-11s, but suffered growing pains when it went to 32 bits. Those
>>>> pains didn't make it any less successful in its new domain, but growth
>>>> obliterated the original design, and the mutually incompatible
>>>> architectures that arose to replace the old one were always
>>>> compromised by the need to support the original.
>>>> 
>>>> I think the same kind of thing is happening now; the global hypertext
>>>> network architecture is in danger of disappearing under the crush of
>>>> applications. Choices being made now are determining the architecture
>>>> of the new order.
>>>> 
>>>> The new application-enriched Web is a bunch of things, self-organizing
>>>> without overall vision. That is probably as it should be. If we can do
>>>> anything at all other than maybe making it a better bunch of things (a
>>>> salutory goal but unrelated to architecture), it would be to
>>>> articulate what kind of system we would ideally like to see and then
>>>> identify practices that do and don't promote that kind of system. To
>>>> state what's obvious to those on www-tag, this "kind of system" is one
>>>> that's not only technically sound and meets current needs, but also
>>>> promotes broader social and economic aims.
>>>> 
>>>> A start would be to review desirable system properties (starting from
>>>> previous discussions, the W3C mission statement, AWWW, etc.) and
>>>> cross-check against these notes to identify points of harmony,
>>>> friction, or puzzlement.
>>> 
>>> I have attempted to describe three interaction examples that may or may not exhibit properties of Web apps architectural additions at http://www.w3.org/2001/tag/2010/10/interaction-examples.html (related also to ACTION-355, Tracker) I hope that these may be helpful in our related discussions.
>>> 
>>> I go back and forth on whether these examples truly describe anything new, but if they do, one item is perhaps the notion that a "client" may expose a resource (its location, for example) to the Web in a non-traditional way (via a call to a Javascript API, rather than by acting itself as an HTTP server). Architecturally-speaking, I am not still sure what else is really different from what is already in AWWW -- rather than simply additions to that architecture which were always available, and sometimes used, but not described in any detail.
>>> 
>>> Regards,
>>> 
>>> - johnk
>>> 
>>>> 
>>>> Jonathan
>>>> 
>>>> On Fri, Jun 4, 2010 at 12:29 PM, Appelquist, Daniel, VF-Group
>>>> <Daniel.Appelquist@vodafone.com>  wrote:
>>>>> I've put together some rough notes that I hope to continue to flesh out over
>>>>> the weekend:
>>>>> 
>>>>> http://www.w3.org/2001/tag/2010/05/web-apps-notes.html
>>>>> 
>>>>> Basically this is a laundry list with links to existing work from John,
>>>>> Ashok and Noah. If there is other work we should review let me know and I
>>>>> will add links here. I think it will be useful to go over some of the
>>>>> existing work and then to step back and say "what are we trying to achieve"
>>>>> here. I also think we need to look at what has happened outside of the W3C
>>>>> community on WebApps Architecture and solicit some support from the
>>>>> community.
>>>>> 
>>>>> Some of these notes are necessarily colored by the work in WebApps wg, Geo,
>>>>> and DAP that I have been involved with.
>>>>> 
>>>>> Thanks,
>>>>> Dan
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>

Received on Friday, 15 October 2010 16:33:50 UTC