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
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 o
>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
colle
On Sat, 2009-06-13 at 05:43 +0200, lu...@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, ass
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
> > whe
> 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 ct
> > 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?
>
On Thu, 2009-06-11 at 06:49 +0200, lu...@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
> 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
В Втр, 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 particu
> On Tue, Jun 9, 2009 at 1:16 PM, erik quanstrom wrote:
> >> still a hash. i'm not doing anything particularly clever for speed,
> >> and it shows in places.
>
> I lied a bit here: in some cases, for example where a particular query
> would involve going through several (up to a couple of thousand
On Tue, Jun 9, 2009 at 1:16 PM, erik quanstrom wrote:
>> still a hash. i'm not doing anything particularly clever for speed,
>> and it shows in places.
I lied a bit here: in some cases, for example where a particular query
would involve going through several (up to a couple of thousand) files
and
> still a hash. i'm not doing anything particularly clever for speed,
> and it shows in places. listing large directories is the slowest
> operation by far, as it would be for most cases where several thousand
> "stat" structures would have to be dynamically created for each entry
> in a directory.
> how are the resultant files looked up? it turns out that generating
> the file hash table was the single most expensive operation for
> upas/fs, given mailboxes with ~10k messages.
> (http://9fans.net/archive/2009/05/106)
still a hash. i'm not doing anything particularly clever for speed,
and i
On Tue Jun 9 14:15:29 EDT 2009, n...@lsub.org wrote:
> With mail2fs I leave messages alone and use all kinds of mail lists
> that contain just relative paths to actual messages. Perhaps nupas
> could do the same.
>
i think that essential strategy is a winner. upas would use
.idx files.
so
With mail2fs I leave messages alone and use all kinds of mail lists
that contain just relative paths to actual messages. Perhaps nupas
could do the same.
El 09/06/2009, a las 20:11, quans...@quanstro.net escribió:
On Tue Jun 9 13:28:55 EDT 2009, mirtchov...@gmail.com wrote:
I think I've me
On Tue Jun 9 13:28:55 EDT 2009, mirtchov...@gmail.com wrote:
> 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 part
On Tue, Jun 9, 2009 at 1:14 PM, Roman V Shaposhnik wrote:
> Lets assume a classical example (modified slightly to fit 9P):
> a synthetic filesystem that serves images from a web cam.
> The very same frame can be asked for in different formats
> (.gif, .png, .pdf, etc.). Is serving
> gif/frame
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 da
Working on a RESTful API lately (which is as close to working on a 9P
filesystem as I can get these days) I've been puzzling over this issue:
is content negotiation a good thing or a bad thing? Or to justify
posting to this list: what would be the proper 9P way of not only
representing different "r
20 matches
Mail list logo
