Re: [9fans] Different representations of the same

Re: [9fans] Different representations of the same

[Chad Brown]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Jun 17, 2009, at 1:54 AM, Charles Forsyth wrote:

>> 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).
>
> it's the other way round: they ought to have represented
> collections of related data and metadata using directories
> instead of inventing rubbish like resource forks.

They sort-of-kind-of got there in Mac OS X with `application bundles'
that are just specially named directories with some canonical
contents.  It'll take another major systems change for them to wean
themselves off of resource forks entirely, I expect.

*chad

[-- Attachment #2: Type: text/html, Size: 1319 bytes --]

Re: [9fans] Different representations of the same file/resource in a synthetic FS

[Roman V. Shaposhnik]

В Втр, 09/06/2009 в 11:27 -0600, andrey mirtchovski пишет:
> I think I've mentioned this before, but on a few of my synthetic file
> systems here I'm using what you describe to slice a database by
> specific orderings. For example, I have a (long) list of resources
> which I'm managing in a particular environment each has an owner,
> type, status and a few static data containers. It's all backed by a
> relational database, but the file server presents different "slices"
> of that to external users, where the directory structure is rigidly
> defined as:
> 
> /
>  available/
>  by-type/
>  by-owner/
>  inuse/
>  ...
> 
> with all data to fill the directories being dynamically pulled from
> the database.

This looks like a slightly different use case than what I'm worried
about. Mainly it seems that you don't really have to deal with
the representations of the same resource, your problem is how to
group these resources in a reasonable fashion. Essentially you're
mapping a relational database to a tree hierarchy.

In your case, the sooner you have the fork of
  by-this/
  by-that/
  ....
in your hierarchy -- the better.

My case is a flip side of that. In fact, my worst case scenario is
that I can't really predict all the representations of existing
resources down the road, thus it appears that I have to push
that part of a filename as close to an actual file as possible:
   /long-path/file.<representation>
I'm almost tempted to consider "virtual extensions":
   /long-path/file ## default representation
   /long-path/file.gif
   ....
   /long-path/file.pdf
but at that point it becomes no more appealing than the content
negotiation techniques of HTTP.

Thanks,
Roman.

Re: [9fans] Different representations of the same

[lucio]

> but at that point it becomes no more appealing than the content
> negotiation techniques of HTTP.

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.  Or use a "clone" style protocol which is more suitable for
the automatic creation of new entities.

The "mntgen" approach is clever, but I find the Schroedinger Cat
nature of it a little daunting.

Of course, you may specifically want to go for a totally different
approach, in which case I plead guilty to not understanding the exact
nature of the solution you're seeking.

++L

Re: [9fans] Different representations of the same

[Roman V Shaposhnik]

On Thu, 2009-06-11 at 06:49 +0200, lucio@proxima.alt.za wrote:
> > but at that point it becomes no more appealing than the content
> > negotiation techniques of HTTP.
>
> 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)?

>  Or use a "clone" style protocol which is more suitable for
> the automatic creation of new entities.

"clone" doesn't quite work for me in REST world (not that it can't
be made to work, it is just complicated).

> Of course, you may specifically want to go for a totally different
> approach, in which case I plead guilty to not understanding the exact
> nature of the solution you're seeking.

I'm simply asking for the best practices. Also, as I admitted in
my original email, I'm not really implementing this in 9P. So I
have an option that is native to the protocol I'm using: content
negotiation (http://en.wikipedia.org/wiki/Content_negotiation)

Now, since 9P doesn't have that I was simply wondering what would
be the agreed upon wisdom to have the same functionality
_cleanly_ implemented in a 9P based synthetic filesystem.

Thanks,
Roman.

Re: [9fans] Different representations of the same

[erik quanstrom]

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

Re: [9fans] Different representations of the same

[Roman V Shaposhnik]

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.

Re: [9fans] Different representations of the same

[Charles Forsyth]

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

it's the other way round: they ought to have represented
collections of related data and metadata using directories
instead of inventing rubbish like resource forks.

Re: [9fans] Different representations of the same

[Roman V Shaposhnik]

On Wed, 2009-06-17 at 09:54 +0100, Charles Forsyth wrote:
> >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).
>
> it's the other way round: they ought to have represented
> collections of related data and metadata using directories
> instead of inventing rubbish like resource forks.

Having thought of this some more, I believe you're absolutely
right. Now, the *only* thing that you don't get if you go
that route is a read/write on a "default" file representation.

Thanks,
Roman.

Re: [9fans] Different representations of the same

[lucio]

> 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)?

Well, assume you have a canonical representation for a given file, I'd
have the ctl file in the same directory.  You'd then use a command
that includes the basename as well as the representation selector to
create the new entry.  If the representation directory already exists,
then the file is added to whatever is already there, otherwise the
directory is created first:

	; ls /n/synthetic
	/n/synthetic/ctl
	/n/synthetic/image.canonical
	; echo GIF image.canonical > /n/synthetic/ctl
	; ls /n/synthetic
	/n/synthetic/ctl
	/n/synthetic/gif
	/n/synthetic/image.canonical
	; ls /n/synthetic/gif
	/n/synthetic/gif/image.canonical # sic

If you need additional depth to the directory, then I think you ought
to be looking to upas/fs and how it manipulates its directory for
further hints.

Whether this is any better than content negotiation may be a judgement
call.  I'll read the wikipedia entry later, thank you for pointing me
to it.

++L

Re: [9fans] Different representations of the same

[Roman V Shaposhnik]

On Sat, 2009-06-13 at 05:43 +0200, lucio@proxima.alt.za wrote:
> > 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)?
>
> Well, assume you have a canonical representation for a given file, I'd
> have the ctl file in the same directory.  You'd then use a command
> that includes the basename as well as the representation selector to
> create the new entry.  If the representation directory already exists,
> then the file is added to whatever is already there, otherwise the
> directory is created first:
>
> 	; ls /n/synthetic
> 	/n/synthetic/ctl
> 	/n/synthetic/image.canonical
> 	; echo GIF image.canonical > /n/synthetic/ctl
> 	; ls /n/synthetic
> 	/n/synthetic/ctl
> 	/n/synthetic/gif
> 	/n/synthetic/image.canonical
> 	; ls /n/synthetic/gif
> 	/n/synthetic/gif/image.canonical # sic
>
> If you need additional depth to the directory, then I think you ought
> to be looking to upas/fs and how it manipulates its directory for
> further hints.

Hm. This looks more complex to me than essentially turning every file
into a "subdirectory" of sorts full of names for representations.

Thanks,
Roman.