Hi Krysztof, Thanks for the feedback. I agree with you in regards to the WAPF doc being very file-centric, however the aim of the document is to consolidate the current industry practices in widget packaging in an attempt to reduce further fragmentation in the widget development and deployment space. In other words, we basically looked at the way Apple, Yahoo!, Opera, Microsoft (vista sidebar), Google, etc, do widgets, and derived requirements from there. We also considered the way users currently install widgets, and how developers create them. We are also aware of widget packages that work as embedded resources (AOL ModuleT and Live.com, etc), and we will definitely address the new requirement those kinds of widgets bring in the next release of the WAPF Reqs doc.
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). However, if you think it does, then that is a design flaw in our document. At this point, we are just trying to gather requirements and we are keeping an open mind to any possible solutions that address each requirement. It would be really helpful to us if you could outline how the WAPF Reqs don't currently meet the technical solution you have proposed. What new requirements would you add? Are there any specific requirements you would get rid of or somehow rewrite? Regards, Marcos [1] http://www.w3.org/TR/WAPF-REQ/#design_goals -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Krzysztof Maczynski Sent: Tuesday, 29 August 2006 9:27 PM To: [email protected] Subject: [WAPFR] too file-centric In my opinion, the Web Applications Packaging Format Requirements document is too much concerned with WAPF documents being files, rather than resources. It mentions even such things as recommended (SHOULD?) extensions, their treatment by operating systems when they don't know the MIME type and by servers, directories (presumably a tree) and length of file names. (If such considerations were in scope of WAPF spec, they'd be as well for HTML, CSS, XBL etc.!) Why not simply reuse existing MIME capabilities and mint a new multipart subtype? This would at hand provide solutions for encoding, linking (cid:), optional compression (gzip support could be required), external bodies, hooks for any accompanying metadata per component (MIME headers) and many other features.
