RE: Manifest (was Re: [WAPFR] too file-centric

Hi Mark,
Discovering the requirements that motivated vendors to use the
package/manifests pattern in the first place is a great idea. I'll do my
best to look further into that. However, my initial gut feeling is that it
would have been done because of practical simplicity for authors (I'm can
only assume that most application developers find it logical and are used to
including a .ini or .pList, or whatever manifest file, or even a custom
config.xml file (as I personally often do)). Please keep in mind that these
initial requirements where based on what is currently out there in an
attempt to reduce fragmentation of the widget development space.
Unfortunately, this also means that some undesirable design practices may be
happening and that we might be forced to take them onboard for the sake of
standardization (please see the Design Goals of the document [1]). 

I need to say that given the current rise in the popularity of widgets and
the trend (pattern) towards having manifests included in the packaging
format, I don't particularly agree that having a manifest adds significant
complexity for authors. All the manifest formats I have investigated are
relatively short (compared to, say, a typical html file) and the language
elements are usually pretty simple (simple keywords (author, version, etc),
only one or two level of nesting max, no namespaces, etc). I don't represent
any vendors, but I have not encountered any significant complaints from
widget developers that writing or including a manifest is too hard/labour
intensive. When compared to the demands on aesthetic quality and technical
complexity of the JavaScript seen in many of today's widgets (particularly
Apple's), my personal experience is that writing the manifest is the easiest
part of creating a widget!:) 

The technical issues that you alluded to (read/write efficiency), however, I
agree with. Similar technical issues have been raised by Ed Voas of Yahoo!
[1] (and also offline). It seems that a real requirement is emerging that
deals with load times and technical efficiency, particularly on the side of
the packaging format. 

I would really like to hear any further thoughts and recommendations you (or
anyone) might have on how to directly improve the contents of the Web
Applications Packaging Format Requirements Doc[3]. 

Thanks again for the feedback, 
Marcos
[1] http://www.w3.org/TR/WAPF-REQ/#design_goals 
[2] http://lists.w3.org/Archives/Public/public-appformats/2006Aug/0159.html
[3] http://www.w3.org/TR/WAPF-REQ/
-----Original Message-----
From: mbaker@gmail.com [mailto:mbaker@gmail.com] On Behalf Of Mark Baker
Sent: Monday, 4 September 2006 7:40 AM
To: Marcos Caceres
Cc: public-appformats@w3.org
Subject: Manifest (was Re: [WAPFR] too file-centric

On 9/1/06, Marcos Caceres <m.caceres@qut.edu.au> wrote:
> Furthermore, our aim is to find the middle ground between what is
currently out there, what the community wants, and the best technical
solutions. Please note that the best technical solution might not be the
easiest solution for developers and end-users, so we need to make
compromises. Please see the design goals for the document [1]. Please note
that the requirements document may imply solutions, but it does not
explicitly give any (apart from using XML as the manifest format).

FWIW, I think it might be presumptuous to assume a manifest.  I suppose it's
likely given that manifests work well in situations where write-efficiency
can be traded off for read-efficiency (such as this one), but they also have
non-trivial drawbacks (e.g. more complicated for authors).  Besides, I'd
prefer we avoid doing design in the requirements document.

I'd suggest we try to discover the requirements that may have motivated the
use of a manifest.  Can any implementors speak to that?

Mark.

Received on Monday, 4 September 2006 01:23:42 UTC