From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain
Date: Tue, 16 Jun 2009 16:12:31 -0700
From: Roman V Shaposhnik <rvs@sun.com>
In-reply-to: <95bd9c720a8d68e2e53b18a31b5c23b5@quanstro.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <1245193951.9958.1909.camel@work>
References: <95bd9c720a8d68e2e53b18a31b5c23b5@quanstro.net>
Subject: Re: [9fans] Different representations of the same
Topicbox-Message-UUID: 0c019d4a-ead5-11e9-9d60-3106f5b1d025

On Fri, 2009-06-12 at 21:56 -0400, erik quanstrom wrote:
> > > I thought you might want a "ctl" file into which you write the
> > > representation you want and that magically creates a new file or
> > > directory.
> >
> > Sure, but if *each* file can have more than one representation then
> > where's the best place for the ctl thing to be? In each subdirectory?
> > At the top of the hierarchy (accepting the full path names, of course)?
> [...]
> > I'm simply asking for the best practices.
>
> generally, plan 9 fs pick a cannonical format if they can get
> away with it.
>
> the right answer is going to depend very strongly on one's
> exact constraints.
>
> if the client knows he's always going to want pngs, it might
> be good to pass png as the spec, as in
> 	; mount /srv/media /n/media png
> i suppose this would be a lot like content negotiation.

Exactly! From where I stand it seems that a particular
representation has to be either part of the name, or
it has to hide in a "invisbible" part of the protocol.

The benefits of having representation spec being part
of the name are obvious -- you are alway know what you're
asking for, plus you can explicitly list representations
if there's more than one.

The only drawback so far seems to be the fact that if one
needs flexibility, then every file becomes a subdirectory.
Not that it is scary or anything, but it smells too much
of resource forks (or may be I'm just too easily scared).

> there are some really wild examples running about.  hackery in
> upas that will serve up x(\.$e)? for any $e in certain circumstances.
> (see upas/ned/nedmail.c:/^plumb.)  the reason for this is so that
> upas/fs can serve up content with type unknown to upas/fs so
> that it can match plumbing rules that expect file extensions.
> the alternative would have been to add an explicitly declared filetype to
> the plumb messages and adding a ruletype to the plumb files.
> i suppose the idea was to not break everyone's plumbing rules.

Interesting...

Thanks,
Roman.