Re: silent semantic changes with reiser4

[Spam]

> Spam <spam@xxxxxxxxxxxx> said:
>> Andrew Morton <akpm@xxxxxxxx> said:

> [...]

>> > 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.

> As you will each time you muck around with your files-are-directories.
> Nothing new there.

>>   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.

> So the _kernel_ has to know about thousands of formats, just in case it
> some blue day it comes across a strange file? Better leave that to the
> applications.

  No,  not  at all. The only think the kernel would need to support is
  the actual meta files and streams - not the contents of the streams.
  That is up to the applications to know and use.

  The  idea  with  plugins  to reiser4 would allow someone to create a
  plugin that would export the thumbnails from TIFF and JPEG images as
  separate streams.

> You will _not_ be able to define a single format for extra data about the
> file, there will be differing extra data for different users (do you
> suggest a root-only file with special writable pouches for "graphical icon
> for the file" for each user on the system?!), so the idea in itself is
> doomed from the start.

  We  do  not need to define a single format. You are locking yourself
  to  the contents of streams and meta files.

  If  someone  likes  the  idea of a plugin that would allow for icons
  then  that  may  be  it. It would be up to application developers to
  know  about  this and use it. Perhaps they could agree on a standard
  even.
>>   I  use  this  in  Windows  quite much.

> Then use it and be happy. No need to screw up Linux for that.

  This  wouldn't  screw anything up besides allowing for extending the
  functionality.  There  is noone that forces you to enable and instll
  plugins,  use  extra attributes or meta info. All of this always was
  optional (as I see it).

>>                                          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.

> The descriptions might make sense to _you_, _now_. No guarantee they make
> any sense (or are in the least useful) for other users on your system, and
> I might want them in arabic or some such. The descriptions might make no
> sense to you in a couple of years.

  So? The same may be for your own word documents etc. It doesn't mean
  I do not find it useful now, or that anyone else might not. Shall we
  not  include  features  because "someone" on the same system may not
  use it? Seems very backward to me.

  If   I   include   a filestream, description.xml, then that wouldn't
  affect  anyone. I would know how to read the file, and that would be
  enough.

>>   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?

> That's their (self-selected) job, yes.

  Yes  and  no.  I  used  them  as example but there are lots of other
  programs  that  can access files. Midnight commander, cp, tar, email
  programs and lots of others.

  besides, I think it would be easier for them to 1) write plugins and
  2)  just  use normal file access method to provide the extra data to
  the users.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/