Unzipping content into current directory widely considered poor practice
Hello, I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that this is the place to direct my feedback on the widget packaging spec, and that I have missed the Last Call deadline by one day. I hope you will consider my plea anyway, since it is based on evaluation of an implementation I only discovered last night. See below for an issue I tried to raise with the implementor. It seems W3C Widget zip packages unload a mess of several files in the current working directory when unzipped. This is unfortunate and I urge you to consider a design that allows things to be kept in a single subdirectory. 1. the dominant convention in modern software development is that you can safely unwrap a .zip or .tar.gz in the current working directory, in the expectation that you'll find only a sensibly named subdirectory. Those who violate this expectation are often seen as making a basic beginners mistake. Encoding such a 'mistake' in a W3C REC both looks bad, and encourages bad practice. 2. by risking a mixup between pre-existing files and those from the archive file, we introduce the risk of confusion and inclarity, making widgets ever slightly harder to learn from. And or those who do try to learn from others works, we reward them by making a mess of their filetree. Assuming 1000 new developers decide each day to explore W3C Widget technology and learn by example, I expect 900+ of them will come with the reasonable assumption that a zip file can be safely unpacked in a directory that has already got other stuff in it (including possibly files with common names like index.html). Mixing up files will be annoying; accidentally overwriting files will be infuriating 3. Are we confident that all unzip tools will ask nicely before overwriting existing files? A quick test on my machine at least gave me a warning. eg. TellyClub:~ danbri$ mkdir w3ctest TellyClub:~ danbri$ cd w3ctest/ TellyClub:w3ctest danbri$ echo 'html6my original valuable html document/' index.html TellyClub:w3ctest danbri$ curl -Os http://berjon.com/tmp/a-widget.wgt TellyClub:w3ctest danbri$ unzip a-widget.wgt Archive: a-widget.wgt inflating: config.xml inflating: icon.svg creating: img/ inflating: img/me.jpg replace index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: Thanks for considering my request. cheers, Dan -- Forwarded message -- From: widg...@googlecode.com Date: Fri, Nov 20, 2009 at 9:24 AM Subject: Re: Issue 4 in widgeon: test widget unzips in current directory To: danbrick...@gmail.com Updates: Status: Invalid Comment #1 on issue 4 by robin.berjon: test widget unzips in current directory http://code.google.com/p/widgeon/issues/detail?id=4 That is something that is imposed on us by the Widgets spec, so you'd have to complain to Marcos I'm afraid. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Re: Unzipping content into current directory widely considered poor practice
On Fri, Nov 20, 2009 at 5:05 PM, Marcos Caceres marc...@opera.com wrote: On Fri, Nov 20, 2009 at 8:48 AM, Dan Brickley dan...@danbri.org wrote: Hello, I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that this is the place to direct my feedback on the widget packaging spec, and that I have missed the Last Call deadline by one day. I hope you will consider my plea anyway, since it is based on evaluation of an implementation I only discovered last night. See below for an issue I tried to raise with the implementor. It seems W3C Widget zip packages unload a mess of several files in the current working directory when unzipped. This is unfortunate and I urge you to consider a design that allows things to be kept in a single subdirectory. 1. the dominant convention in modern software development is that you can safely unwrap a .zip or .tar.gz in the current working directory, in the expectation that you'll find only a sensibly named subdirectory. Those who violate this expectation are often seen as making a basic beginners mistake. Encoding such a 'mistake' in a W3C REC both looks bad, and encourages bad practice. 2. by risking a mixup between pre-existing files and those from the archive file, we introduce the risk of confusion and inclarity, making widgets ever slightly harder to learn from. And or those who do try to learn from others works, we reward them by making a mess of their filetree. Assuming 1000 new developers decide each day to explore W3C Widget technology and learn by example, I expect 900+ of them will come with the reasonable assumption that a zip file can be safely unpacked in a directory that has already got other stuff in it (including possibly files with common names like index.html). Mixing up files will be annoying; accidentally overwriting files will be infuriating 3. Are we confident that all unzip tools will ask nicely before overwriting existing files? A quick test on my machine at least gave me a warning. eg. TellyClub:~ danbri$ mkdir w3ctest TellyClub:~ danbri$ cd w3ctest/ TellyClub:w3ctest danbri$ echo 'html6my original valuable html document/' index.html TellyClub:w3ctest danbri$ curl -Os http://berjon.com/tmp/a-widget.wgt TellyClub:w3ctest danbri$ unzip a-widget.wgt Archive: a-widget.wgt inflating: config.xml inflating: icon.svg creating: img/ inflating: img/me.jpg replace index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: Thanks for considering my request. I spoke to Dan about the above offline, we feel that adding the following non-normative authoring guideline into the specification would be sufficient to address Dan's concerns: Just a quick note to confirm that this would satisfy my concern for now. I hope a subdirectory based approach can be specified in the future, but for now I'm happy with this resolution. Also to ack Art's response which arrived as I type this. Thanks both. May 2010 not be like 1984 :) cheers, Dan
Re: Is there proposal of accessing metadata of media files?
Hi Robin, On Thu, Oct 8, 2009 at 12:40 AM, Robin Berjon ro...@berjon.com wrote: Hi, On Oct 7, 2009, at 15:39 , Arthur Barstow wrote: Soohong, Media Annotations WG - would you please provide a short update/status and plans regarding your Media API spec? Also, is this the most recent API document: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html Could you also copy DAP (cc'ed) please? We have an API in our list (Gallery) that could probably be expressed simply with File System plus some metadata. We certainly wouldn't mind being able to declare an easy victory there. [For those who are missing the context, it's at http://www.w3.org/mid/de062981-b996-4da0-a2de-e8fce3475...@nokia.com ] Do you have any more details on DAP's Gallery requirements? I found my way to http://dev.w3.org/cvsweb/~checkout~/2009/dap/api-reqs/Overview-FPWGN.html?rev=1.6content-type=text/html;%20charset=iso-8859-1#gallery which says [[ This interface: * must enable listing all available gallery sources, their names and types; * must enable finding content inside a gallery; * must enable adding, updating, and removing content from a gallery; * must expose metadata about the gallery's content items (copyright, author, media-dependent information, etc.). ]] Is that the latest word on the topic? What content types are in scope for these galleries? anything that might live in a filesystem? Is it supposed to allow for remote services too (eg. a list of media streams). Context: Lately I have been looking into 'media centre' APIs (xbmc, boxee, itunes etc) for the NoTube project. These typically address some or all of the above requirements plus a bunch more (eg. pause/play/stream etc content). I am working up a proposal to expose some of this functionality using XMPP (aka Jabber), such that an EPG or content browsing app running on a phone could communicate over XMPP to a TV or media centre. The use of XMPP for messaging is to avoid the difficulties of exposing HTTP/REST services in a home or NAT setting, and an attempt to sidestep the need for devices to be on the same location network. My impression of DAP is that it's more for device-local access (so less concern for async interfaces perhaps?). Is that correct? If any of this is close to our concerns, let's stay in touch.. cheers, Dan
Re: Is there proposal of accessing metadata of media files?
On Tue, Oct 13, 2009 at 9:16 PM, Felix Sasaki felix.sas...@fh-potsdam.de wrote: Hello Dzung, sorry for jumping in, but from http://dev.w3.org/cvsweb/~checkout~/2009/dap/api-reqs/Overview-FPWGN.html?rev=1.6content-type=text/html;%20charset=utf-8#gallery Exposing metadata is tricky, often giving a choice between creating an endless ontology or building an open-ended system that guarantees no interoperability. I liked that observation. Basically it says that you can take the path of hardcoding something quite fixed, eg. getTitle() getDescription() getSize() ...and have a rigid, predictable system but hard to manage since everyone's requirements need to be addressed by the API itself... or you can have an API that is much more neutral, and the fields requested are passed in as arguments (perhaps even a full query language). In the latter case, the basic API isn't enough to guarantee interop; the basic schema or query structures needs to be agreed and documented too. I am not sure what you are looking for: - an ontology defining mappings between existing metadata (being defined by media annotations working group (MAWG)) - new metadata properties defined as an ontology (not defined by MAWG) - an API which reflects the mapping of existing properties in the ontology to access methods for metadata (provided by MAWG) - an API for low-level reading mechanisms (not provided by MAWG - e.g. for XML-based formats provided by an XML-parser) Another candidate perhaps: a set of standard queries (expressed in SPARQL) that can match against some/all of this metadata, and whose API is an SQL-esque tabular resultset. cheers, Dan ps. for some very old (SVGOpen 2004) notes on this see http://www.w3.org/2001/sw/Europe/200407/svgwebapps/ http://www.w3.org/2001/sw/Europe/talks/200409-svgopen/slide1-0.html
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Williams, Stuart (HP Labs, Bristol) wrote:
Well there are ways around that, add a package description
or meta-data file either at the root of the package or at
each directory level and have it carry media-type information
- or use 'magic numbers' or (if you really must - in the
absense of other authoritative information), sniff/guess
though I think that should be the least preferred option.
Right. The new proposal is that we use file extension mappings to MIME
types, and if that fails, result to sniffing. We are reluctant to
introduce a meta-data format at this point.
(Just allow RDFa+XHTML and leave it to the marketplace...)
For version 2 of widgets,
it might be useful to either introduce the meta-data format or have
an Apache-like file extensions to MIME type mapping. For example:
image/gif .gif
Note however, that widget engine in the wild have no problem working
without MIME info. From what I have seen, they all do just fine either
sniffing or using file extensions to derive the content types.
Anyway - that zip files don't intrinically maintain such
info is not a show stopper - though I would have thought that
carrying media-type information is a natural requirement for
a packaging format for the web.
I'm not sure it is. When a MIME type is registered with IANA, the file
extension is also registered.
What is registered (RFC 4288 section 4.11) is a list of file name extensions
commonly used with the media-type.
It does *not* reserve the extension for exclusive use with that media-type.
It does *not* prevent other arbitrary file name extension or indeed
no-extension being used.
So... yes not a bad hint, but nothing is certain.
So one has a standardized way to derive
the media type for a file by the file extension.
Not with certainty...
So this seems like a very small piece of metadata ('this filetree
follows the IANA filename to media type mappings') has a lot of value.
If the versions of the IANA mapping are easily identified, the metadata
becomes a URI rather than a single bit. Either way, you can gain a lot
from not a lot, I think.
cheers,
Dan
--
http://danbri.org/
