[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ls /dev



On Fri, Jul 28, 2000 at 11:54:07PM +0200, Marcus Brinkmann wrote:
> On Fri, Jul 28, 2000 at 11:14:35PM +0200, Tomasz Wegrzanowski wrote:
> > 1)
> > UI app is used to show number (+ size, maybe) of all files in every
> > subdirectory.
> > 
> > dir a is on ext2fs. dir b is on ftpfs.
> > 
> > How do you tell user app that it's ok to ckeck subdir a,
> > but not ok to check subdir b ?
> 
> What makes you think it is not okay to check subdir b?

( Sorry if ``is used to'' grammar was ambiguous,
  I was talking about default convention, not explicit usage )

Users usually don't want UI app to provide them with informations,
that, although quite useful, would make them have to wait awfully
lot of time.

> If any clients thinks that ftpfs should not be entered, then by all means
> make the client configurable to take this into account.

It's not that easy.
If I have ~/.signature file dynamic (it doesn't have to be separate translator,
my whole home dir could be translated), why would it have to run 'fortune -s'
or whatever is under ~/.signature, just to see its size, even if its non true ?

> There is no global parameter that can know about all server/user
> preferences. (What about user written translators, for example?)

It could be per-file flag provided by every translator,
plus per ~/.appname settings what to do with this flag.
Only a few apps, like mc and ls would care.

> > There must be some way for program to tell this difference.
> > This has nothing to do with ``translatorness'' of the file.
> 
> Well, if you really think that those are important factors, write a
> translator that is stacked on the root node and filters file request in some
> configurable manner, providing dummy information for inconvenient nodes.
> The Hurd translator concept allows this, so you can do it if you think it is
> a good idea without imposing your view on other people.

And here is the problem that I can't.
Individual translators would have to provide some information if data is
available right now or not (you aren't serious that such translator would
have to know every translator type in existence and check underlying translator).

Then, it would be possible to write such translator.
But then, it would be also possible to patch mc to suport this.

> I think it is reasonable to change mc to show translator settings, and make
> it user configurable if a translated node should be stat()ed or not.
> But I don't think it is reasonable to seperate any of the cases you consider
> above. However, we don't need to agree, because the Hurd is such a fantastic
> thing to allow for arbitrary extensions :)

Remember that every node is translated. It might be per-file translator
or per-dirtree translator, but every node is translated anyway.



Reply to: