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

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.

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.

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 Thursday, 14 October 2010 21:08:41 UTC