Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Hi Stuart,

On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol)
<skw@hp.com> wrote:
<snip>
>>
>> Unfortunately, widgets/zip do not maintain media-type information.
>> That information is derived from content-type sniffing heuristics as
>> defined in HTML5 [1].
>
> [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?]
>

Web Apps does not have a problem having a dependency on HTML5
(particularly if the relevant section of HTML is proven to be stable
by interoperable implementations). It might mean that Widgets sits on
CR for 10 years, but that's ok with me at least. Sitting in CR for
endless years didn't do any harm to CSS. However, if it does becomes a
process problem for Web Apps, we might lift the relevant text out of
HTML5 and put it in the Widgets spec.

> 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. 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. So one has a standardized way to derive
the media type for a file by the file extension. So I guess it might
make sense to have a table of common file extensions and related MIME
types baked into the Widget spec for formats that the widget spec
mandates support for (e.g., .html, .css, .js, .gif and so on).

>> > Other characters than / and ! could be choosen as path and
>> > container separators respective.
>> >
>> > Could this or something like it meet your requirements? If
>> > not... which ones does it fail to meet?
>> >
>>
>> Nice solution. But, unfortunately, widgets don't support inner
>> packages (they inner packages are treated as arbitrary files) and we
>> have no requirements that call for inner package access.
>
> Ok... but you answered a different question.
>
> I asked which of your requirements would an approach like this *fail* to meet?
>

ok, sorry. I should have answered that correctly:

1. The <path> part of the "scheme://<authority>/<path>/" does meet our
requirements iff by <path> you mean path as defined in RFC2396 (with
the ability to be an iPath as in RFC3987).

2. the "scheme://<authority>/path" is the bit Web Apps really needs to
sort out. I.e., what will we call the "scheme"?: widget:? zip:?
package:? or something else? what will be the <authority>? will it be
the package itself: zip://myZipfile.zip? or the widget engine
zip://engine/someZip.zip/? and so on... do we need an authority at
all? I think these, and probably about a dozen more questions, need to
be addressed before we jump the gun and start solving secondary use
cases (addressing inner inner packages)

> I could paraphrase your response as:
>
>        "That would work, but it does more than we need."
>
> Dan Brickley's response[a] emphasised the need for nesting packages in packages. Even if that is not a capability that widgets would need to use, widgets could still share the same syntax.
>

Dan's problem may be a general problem, but I need to empathize that
it's not a requirement in the widget world. We could live with a
shared syntax, of course. However, what worries me is bloating the
scheme with features that may be rarely used, expensive to implement,
and introduce another attack vector. For those reasons alone, I would
like us to develop the scheme to be as simple as humanly possible and
meet the most fundamental use cases/requirements ([1], [2]) before
anything else.

> Anyway... I think that my sketch shows that there is a potential to develop a media-type + fragID-syntax based solution to the package component/widget addressing problem.
>

Completely agreed. But can we please work on the "scheme", "authority"
and "path" bits first?

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au


[1] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing
[2] http://dev.w3.org/2006/waf/widgets-reqs/#r36.-

Received on Monday, 1 December 2008 15:28:30 UTC