From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <95bd9c720a8d68e2e53b18a31b5c23b5@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 12 Jun 2009 21:56:20 -0400
To: 9fans@9fans.net
In-Reply-To: <1244854934.9958.1843.camel@work>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Different representations of the same
Topicbox-Message-UUID: 0a18eb5a-ead5-11e9-9d60-3106f5b1d025

> > 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.

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.

- erik