Hans Reiser wrote on Mon, 30 Aug 2004 23:43:13 -0700: > Alexander G. M. Smith wrote: > >Are you sneaking in file types there? Just how does a file know which > >plugins it supports? > > we have plugins with pluginids, is that what you mean by file type? I > think they are a bit different from file types.
>From your white-paper: "Every file possesses a plugin id, and every directory possesses a plugin id. This plugin id will identify a set of methods." Functionally this is very close to a file type. It classifies the files into related groups, maybe not as finely as a MIME file type which can distinguish between multiple varieties of text files. A file type would tell us that a file is a text file and can be opened by certain applications (text/e-mail can be opened by e-mail reader, text editor, etc) and have other properties (lists of standard attributes, default icon). A plugin ID says that the file can use text related plugins (like a word count, or XML structure as a subdirectory). In both cases there is a global repository (I assume) that associates the file type or plugin ID with a list of things about it. You could combine the two concepts, just have a file type ID that in the global repository specifies what plugins it can use as well as the userland properties (MIME string, etc) of that kind of file. Or at least make the type ID available to userland so it can be used there. Or is this binding irrelevant? How often does the file type the user sees not match the plugins desired for the file? Or can a new subtype be defined for just that file? Which may mean that we need something better than MIME strings for types (something which has inheritance). - Alex
