> Spam <[EMAIL PROTECTED]> wrote:
>>
>> 
>> 
>> > Spam <[EMAIL PROTECTED]> wrote:
>> >>
>> >> 
>> >> 
>> >> > Spam <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>    Yes,  for  example  documents,  image  files  etc. The multiple data
>> >> >>    streams  can  contain thumbnails, info about who is editing the file
>> >> >>    (useful for networked files) etc. Could be used for version handling
>> >> >>    and much more.
>> >> 
>> >> > All of which can be handled in userspace library code.
>> >> 
>> >> > What compelling reason is there for doing this in the kernel?
>> >> 
>> >> 
>> >>   Because  having user space tools and code will make it not work with
>> >>   everything. Keeping stuff in the kernel should make the new features
>> >>   transparent to the applications.
>> >> 
>> >>   Applications  that support the new features will benefit, all others
>> >>   will continue to work without destroying data.
>> 
>> > Sorry, but that all sounds a bit fluffy.   Please provide some examples.
>> 
>>   We  already had the examples with cp and mv. Both should continue to
>>   work and the files will still be copied. The same with Konqueror and
>>   Nautilus.  Files  and  their  meta-files/streams/attributes  will be
>>   retained as long as applications are using the OS API.
>> 
>>   However,  if  things  are  to  implemented  in  user-space, then old
>>   applications  will not work correctly and there is risk that all the
>>   extra information will be lost or corrupted.
>> 
>>   You  said  it  would be socially hard. I think it would be very much
>>   close to impossible to get it right. Imagine that Gnome and Nautilus
>>   would  implement  support  for  these. I doubt that cp, mv, KDE, mc,
>>   app-xyz  would  implement  this anytime soon and in the meantime the
>>   data is at risk.
>> 

> No.  All of the applications which you initially identified can be
> implemented by putting the various bits of data into a single file and
> getting applications to agree on the format of that file.

> For example, some image file formats already support embedded metadata, do
> they not?

  Yes, JPEG, TIFF and PNG files for example. But, if you modify any of
  these  with  an application that doesn't support the extensions then
  you will loose them.

  Also,  you  are thinking _very_ narrowly now. There are thousands of
  file  formats.  Implementing  the  support  for  meta-data/ streams/
  attributes  in  the  kernel  will  make  it  possible  to  use  this
  generically for all files.

  I  use  this  in  Windows  quite much. I put information description
  fields  for  lots  of  different  files. These descriptions are then
  searchable etc. I could use the command prompt to copy the files and
  the descriptions would still be there.

  Secondly, do you expect file managers like Nautilus and Konqueror to
  support  every piece of file format on the planet so they could read
  information directly from the documents?

  ~S


Reply via email to