In general I find "virtualizing" things is most adaptable.  Some sort of
hook or hooks that allow customizable/barterable/saleable executable code
to act on the information. This could include being able to do things like
check magic and version numbers on files as well as suffi.  The details of
what is checked left to the domain of "the plug in" vendor and not be
defined as part of iVS itself.  iVS only defining the protocol and API by
which customization can be accomplished, adding features to the base
distribution of iVS being including canned modules that do not require
altering the kernel and excluding other possibilities.


At 03:15 AM 2/16/00 -0800, Paul Sander wrote:
>>--- Forwarded mail from [EMAIL PROTECTED]
>
>>Paul Sander wrote :
>>|| >--- Forwarded mail from [EMAIL PROTECTED]
>>|| 
>>|| >Very yes. Though unix has extensionless files, the web and MIME are
defacto
>>|| >using suffixes for file type id.
>>|| 
>>|| Well, they do and they don't.  MIME provides a way of supplying the
type of
>>|| some content along with the data itself.  That mechanism in itself
does not
>>|| rely on file extensions.  However, certain software (such as email
clients
>>|| and web servers) use lookup tables to map file extensions to MIME
types on
>>|| those occasions where they must somehow conjure up a type without
asking a
>>|| user for it.  But once a file is encoded with MIME, its original
extension
>>|| becomes meaningless because its type is carried along explicitly.
>
>>I think that "mime type" is mostly a side-issue.  It gives a nice set
>>of names that an admin might want to use, but doesn't help much
>>more.  New files will have to be classified and the classificatio
>>that has been determined will have to be stored in a control file
>>(not embedded in a wrapper around the actual data the way mime is put
>>on mail).
>
>How about storing it in the RCS file, using a newphrase in the admin
>section?
>
>>            The classification would be by the user providing an
>>explicit type or by an add hook examining the file (both the data
>>content and the filename/extension to the extent that the platform
>>provides those) and trying to classify it automatically.  The
>>classification hook should have a way of giving up, so that the
>>fallback position of asking the user is used.
>
>Agreed.  Or fall back to a generic type and allow the user to transform
>it to the proper type later.
>
>>--- End of forwarded message from [EMAIL PROTECTED]
>

Reply via email to