9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Roman V Shaposhnik <rvs@sun.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Different representations of the same
Date: Tue, 16 Jun 2009 16:12:31 -0700	[thread overview]
Message-ID: <1245193951.9958.1909.camel@work> (raw)
In-Reply-To: <95bd9c720a8d68e2e53b18a31b5c23b5@quanstro.net>

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.




  reply	other threads:[~2009-06-16 23:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-09 17:14 [9fans] Different representations of the same file/resource in a synthetic FS Roman V Shaposhnik
2009-06-09 17:27 ` andrey mirtchovski
2009-06-09 18:10   ` erik quanstrom
2009-06-09 19:01     ` andrey mirtchovski
2009-06-11  3:44   ` Roman V. Shaposhnik
2009-06-11  4:49     ` [9fans] Different representations of the same lucio
2009-06-13  1:02       ` Roman V Shaposhnik
2009-06-13  1:56         ` erik quanstrom
2009-06-16 23:12           ` Roman V Shaposhnik [this message]
2009-06-17  8:54             ` Charles Forsyth
2009-06-18  0:20               ` Roman V Shaposhnik
2009-06-13  3:43         ` lucio
2009-06-16 23:15           ` Roman V Shaposhnik
2009-06-09 17:30 ` [9fans] Different representations of the same file/resource in a synthetic FS J.R. Mauro
2009-06-17 17:05 [9fans] Different representations of the same Chad Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1245193951.9958.1909.camel@work \
    --to=rvs@sun.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).