Re: Draft of Requirements and Use Cases for Open Web Application Store

On 14 Jan 2014, at 10:14, Marcos Caceres wrote:

> Hi Jonathan,  
> Just following on from Scott's comments...  
> 
> On Tuesday, 14 January 2014 at 09:44, Scott Wilson wrote:
> 
>> Thanks Jonathan,
>> 
>> On 13 Jan 2014, at 02:28, 전종홍 wrote:
>>> Dear All,
>>> 
>>> I’m happy to announce this draft.
>>> 
>>> We have made a new draft document on the github. The title of this document is “Requirements and use cases for OWAS(Open Web Application Store)”.  
>>> 
>>> http://hollobit.github.io/ows-req/
>>> 
>>> I hope we can start to discuss for this kind of topic on the mailing list,
>>> and I hope also it could be help to reach the open web application store environment.
>>> 
>>> If you have any comment and suggestions, please feel free to send.
>> 
> 
> 
> General comment: the document is really hard to read. It contains a lot of grammatical and spelling mistakes that makes it really hard to follow - it could really use a once over from a native english speaker, as currently it reads as if it has been machine translated. Also, section "3.1 Storefront" is still in Korean :)   
> 
>> I don't think the sequence diagrams are very useful, as this is mostly describing the internal behaviour of the store. The key areas for requirements are where a store interacts with other systems. (Likewise, I think we don't need to know the specifics of how a store handles authz for its publishing process, just that it happens.)
>> 
>> So perhaps the requirements could be framed more in terms of the services that a "black box" OWAS provides? E.g.:
>> 
>> - Searching the store
>> - Browsing the store (by category, most recently added, most popular etc)
>> - Get the metadata for a web application
>> - Submitting a web application for inclusion
>> - Submitting an updated version of a web application
>> - Withdrawing a web application from the store
> 
> 
> My concern is that these are just requirements for a website (and makes assumptions that apps are self contained units, which on the Web they are not). Each store will (and probably should) handle it's own processes so I'm not really getting what is standardisable here? Also, the processes seem to be much more limited then what one would commonly find with a search engine like Blink or Google - which are really the web platforms actual "app stores" (i.e., how users commonly find the services they need - including services that list other services/or "apps").  

This is true enough. Here's our UC for you:

Apache Rave is an enterprise portal that includes web applications (W3C Widgets and OpenSocial Gadgets). It has its own internal "widget store" that users can browse to add to their pages and sites. 

However, Rave can also connect to an external Marketplace to add more widgets/gadgets. It connects to this store using a standardised API, allowing organisations to connect to a shared marketplace; this may be region- or market niche-specific, subscription-based etc.

The API itself is a facade on top of Apache Solr. The metadata model is mostly the same kind of stuff you find in W3C Widgets with a few extra fields, as a JSON array. The API methods are based on these developed for the Edukapp app store project:

http://code.google.com/p/edukapp/wiki/JsonApi

So this only covers the search/browse/get cases of the above list (it also does installation, but thats just a case of parsing the download URL or remote host URL of the widget). The publishing parts are implementation specific; one of marketplace apps has a regular webform type submission process,  one has a more commercial publishing sort of model, and another seems to fill up using googling, scraping, and converting old Opera widgets :)

Is it worth standardising this API outside of Apache and the handful of marketplace solutions I know about? Probably not, unless there was interest from other organisations. It seems a better fit for niche markets and enterprise portals than general web apps.

> 
>> And the data and metadata it manages and potentially exposes:
>> 
>> - Application metadata (e.g. from the manifest)
>> - Discovery metadata (e.g. additional classification in the store)
>> - Usage and user metadata (comments, reviews, ratings, downloads, likes etc)
> 
> As above. For example, Mozilla's marketplace has it's own API [1] to expose that stuff - but requirements and availability of those APIs is constantly changing to serve the needs of our community (thus I'm not sure how such a standard would help Mozilla - but to verify what we are doing or to poke holes in the requirements document).  
> 
>> There is also the much more problematic area of runtime access, as this depends on the application format and runtime model, e.g. whether its hosted or packaged. (We implemented separate parallel APIs for W3C and OpenSocial, for example).
>> 
> 
> Agree. Ideally, it should all remain "one Web" and the whole concept of hosted and packaged will go away (at least runtime security model should not be much different from one type to another, unless one is running apps from a proprietary platform such as Chrome Apps or FxOS's packaged apps).
> 
> [1] http://firefox-marketplace-api.readthedocs.org/en/latest/