Re: starting point: manifests, configs, and the such

On 24 Nov 2011, at 17:20, Brian LeRoux wrote:

> This old chestnut. First we have W3C specs:
> 
> - CACHE MANIFEST [1]
> - config.xml from the widget spec [2]
> 
> And then we have analogues in the native app dev world:
> 
> - Android: AndroidManfiest.xml [3]
> - iOS: Info.plist [4]
> - BlackBerry: config.xml [5] <-- yay!
> - WindowsPhone: App.xaml, WMAppManifest.xml ... possibly others
> - Bada: Application.xml, Manifest.xml

In Apache Wookie and Apache Rave another case we want to handle is Widget-Gadget interoperability. So making sure there aren't major conflicts or gaps at the basic metadata level between Widgets and OpenSocial when platforms want to support both.

> 
> And then we have other places that have embraced JSON:
> 
> - webOS
> - Symbian
> - Mozilla Open Web Apps
> - Chrome Apps Store Apps
> 
> All of the things (listed earlier) tend to abstract the metadata
> around the contents of the executable package. So, we have some good
> precedents. In the PhoneGap project we decided to embrace and extend
> from config.xml as our starting point. XML, while its lost its shine
> lately, does have explicit mechanisms for validation and extension
> whereas JSON does not (not really).

My rule of thumb is: if its a document that an author will edit, its better off as XML. If its a representation returned by an API call, its better off as JSON.

(I think in the Mozilla case, they were mostly thinking about the data returned by querying an app store about an app, rather than the content of the metadata that an author edits when they create it.)

> Point being, I think this is our most fundamental starting point. We
> can't have an installable web app without this spec, and the spec for
> the config.xml has been evolving but a few things remain that need to
> be addressed:
> 
> 1. CACHE MANIFEST use case
> 2. items found in the various native platforms not yet addressed
> 3. the concepts around WebIntents/WebActivities

+1 on starting with config.xml

+1 on intents, I think that will be important.

Another thing we're missing is screenshots, which are used when unpacking widgets in the various stores and repositories. Personally I think we can do something simple like treat any supported image files in a top level folder called "screenshots" in the widget package as usable for screenshots when the widget is submitted to a store.

Something common with OpenSocial implementations is using an editor in the container for making changes to preferences, rather than in the widget itself. This could probably be handled OK for widgets too, for example by recommending that containers that do this fire a storage event at the widget context so the widget author can use a listener for checking if any preferences were changed.

FInally there is this big area of "inter widget communication" [1] where I've seen a lot of work going on, though this is much more for the case like Apache Wookie and Apache Rave where you have a bunch of widgets in a single web space like a profile page or workspace. I think Robin was right that intents could handle some of these cases... but not all of them.

[1] https://docs.google.com/document/pub?id=1aUScFats9A0zBUqNbkw9J2XhmupKfA38eU0wYjs81FM

> 
> * * *
> Thoughts on the three points above? Should I start collecting this
> info on our Wiki?
> 
> 
> [1] http://www.w3.org/TR/html5/offline.html#manifests
> [2] http://www.w3.org/TR/widgets/
> [3] http://developer.android.com/guide/topics/manifest/manifest-intro.html
> [4] http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_workflow/115-Configuring_Applications/configuring_applications.html
> [5] http://docs.blackberry.com/en/developers/deliverables/30182/Creating_a_BB_Widget_configuration_document_834664_11.jsp
>

Received on Thursday, 24 November 2011 21:27:58 UTC