Fwd: design goals vs mechanisms (was: Re: Let's do some coding :-)

[Michal Suchanek]

ehm, I forgot the cc

---------- Forwarded message ----------
From: Michal Suchanek <address@hidden>
Date: Nov 1, 2005 12:10 AM
Subject: Re: design goals vs mechanisms (was: Re: Let's do some coding :-)
To: Marcus Brinkmann <address@hidden>


On 10/28/05, Marcus Brinkmann <address@hidden> wrote:
> At Fri, 28 Oct 2005 15:08:49 +0200,
> Michal Suchanek <address@hidden> wrote:
> > > At Wed, 26 Oct 2005 22:43:06 +0200,
> > > Bas Wijnen <address@hidden> wrote:
> >
> > > If you want stability, you probably want to do some of the following:
> > >
> > > * try formal verification
> > > * allocate a fixed amount of resources statically up front,
> > >   instead dynamically at run time.
> > I kind of dislike this. That is one of the things that is nice in
> > Hurd/Mach: you have no limit on the size of strings like filenames. I
> > do not think I would like a filename that has 1M characters, but I do
> > not know what is the  "reasonable limit" for filename length.
>
> I agree with your dislike, and I am struggeling.  But there is no way
> around this.  Unless you want to give the user unlimited storage and
> cpu time, the story will end at the end of storage for that user.

Although the amount of storage and cpu time available to the user
process is limited the limit is not determined by design for all
processes of all users.
So I still do not see anything that tells me how long a filename cannot ever be.

>
> > On the other hand, it may be possible to write servers that use bound
> > amount of their own resources to serve possibly unbound requests for
> > which the clients supply their resources.
>
> Actually, this is a requirement if you want proper resource
> accounting.  In fact, the server should allocate _zero_ of their own
> resources to server, let's say, potentially unbound requests of a
> client.
>
> In EROS, most servers run completely on their clients resources, and
> _only_ serve that client.  In this case, there is no problem.
>
> Note that there is a slightly different problems: It is not so easy to
> design robust communication channels that carry payloads with buffers
> of arbitrary length.  So, there is also a practical limit.

The filesystem or other means of storage still needs a way to store
and transport large files. The problem must be solved to get a usable
system.
I would think that the usual read() semantic which specifies the size
of client buffer can be used to read an object in chunks.

>
> For more information, maybe check out:
>
> http://citeseer.ist.psu.edu/shapiro03vulnerabilities.html
>
> > For one I do not see why such names have to be used by the system at
> > all. The names can be stored as another "content fork", and files can
> > be identified by some handles. Programs that show the files to users
> > can then read the name in the same way they would read the data.
>
> I think the problem here is the lookup operation.  The user doesn't
> want to look up files by the handle, but by the name.

In my experience the user wants to see all files (in a directory) or
all files that contain 'foo' either in their name (or better yet in
their content :).

Neither name lookup nor handle lookup provide this funcionality. In my
view both can be used equally well as the foundation for the desired
interface.

Many (most?) people also find hierarchical filesystems confusing.


Thanks

Michal


--
             Support the freedom of music!
Maybe it's a weird genre  ..  but weird is *not* illegal.
Maybe next time they will send a special forces commando
to your picnic .. because they think you are weird.
 www.music-versus-guns.org  http://en.policejnistat.cz