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

Well, I wonder if we might introduce another step between
"resource" and "representation" which is "application resource
in identified state", so that the representation isn't a
representation of the resource, but a representation of the
resource in that state.

Does it make sense to talk about the route as a resource independent 
of the application that calculates or draws routes?

The relationship of this to MIME and the web is that only
representations have Internet Media types or charsets or whatever.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: John Kemp [mailto:john@jkemp.net] 
Sent: Thursday, October 14, 2010 1:02 PM
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 14, 2010, at 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".

Does that in any way (in your opinion) correspond to the traditional idea of a "representation" of the resource?

>  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".  

Is this not also a (graphical) representation of a 'route' resource where the route resource consists of a set of co-ordinate pairs, and the representation is a series of lines drawn on a graphical map which contains the co-ordinates of the route?

> 
> 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.

Is the "application" here then something that is capable of zooming/panning a graphical map according to instructions? I agree that one might also transfer application state ("amount of zoom applied to map", say) but I don't think this is necessarily the same thing as the resource (the map, or route) displayed by the mapping application. The point being that what ends up being viewed by the user is the combination, by an application, of multiple (Web) resources. 

> 
> 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".

An instance of an application has resources too (beyond the ones which are represented by the application based on information acquired from various servers), yes. 

> 
> 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.

And some elements (for example, the GPS co-ordinates of the user-agent) may not be communicated in the URI but only to a single server, which asks for the information by calling a Javascript function, executed on the user-agent. 

> 
> 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.

There is a lot of sharing of URIs which are not intended for public consumption, and provided they are transported securely,  have certain other properties (one-time use, limited-time use etc.) and/or are used in low-value transactions (photo-sharing, say) it does seem reasonable to use URIs for that purpose. 

Regards,

- johnk

> 
> 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:12:05 UTC