Re: [Summary] Meta-data/filesystem-encapsulation

[Leareth <leareth geocities com>]

Ok, as this is not a flame war, I wont call you a short sighted fool, with
limited imagination. I'll get to the point. WE NEED METADATA FOR A GOOD
GUI!!!!.

We need metadata that DOESN'T fall apart if you play with the files in the
shell, BECAUSE IT"S A VERY COMMON WAY OF EDITING/MOVEING FILES,
just becuase we give people a good gui, does not mean that they will give up
there shell, I know I wont! But if I keep lossing metadata(on of the only
reasons I use gui's at all...) every time I make heavy use of the shell, guess
what? I leaveing the gui, not my shell. While I agree we should:

	A: Have very good support for system's that chose not to use
LD_PRELOAD, or the optional libc patch we provid as a side option, with
good file rerecignization for broken links, and a per user database for people
who don't have access to there sub system, and are on a system that does
not support LD_PRELOAD(or they chose for some reason not to use it).

	B: We should have a very large database of mime types for defaults.

BUT!!! This should NOT be the default!
We should prove the most robust, non system specific,  per file metadata that is
not open to broken links simple through shell commands! Just because it's
not 100% universaly crossplatform does not mean it's evil! A good enough
setup should be able to do this on any system that you can use LD_PRELOAD
on, and work even better if patching libc is an option on the system. Now
static apps are, A: a bad idea for the most part(good for recovery tools though,
if libc breaks for some reason, you still have a working tool set :), and B:
rare. We do not need to worry about these, as any solution we find will break
in these cases, so we should just provid a user updateable database so people
will be able to check if there fav app on some system is static by default.

On Mon, 17 Aug 1998, Daniel Veillard wrote:
>Ok, I never said anything yet on this subject, expecting that the
>heresy would stop soon by itself, unfortunately no :-(
>
>> > 	This shouldn't even be an option, unless you plan on porting ext2 to
>> > every supported *nix as a whole, and convince all those administrators to
>> > convert from jfs, ufs, etc. which will NEVER happen. GNOME != Linux, even
>> > though it is being developed there. And OS/2 is fine, it has lots of good
>> > ideas to inherit.
>> 
>> You miss the point (which may not be in this letter but in another) - ext2
>> has "spare" entries in its data structure.  I'm sure other filesystems do
>> as well.  Any of these can be used.  ext2 should simply be the easiest.
>
>  I want to be able to use Gnome seamlessly on ANY filesystem, without knowing
>wether it's mounted from a Sun, a Linux box with xiafs, a Cray, AFS or 
>whatever.
>Posix compliance is the #1 rule of any development on Linux (except on the few
>case where one can prove that Posix is broken). This was the guideline from
>the very beginning (you can trust me on that), and one of the reasons of
>Linux success. 
>
>> > > Probably best is a GNOME wrapper class around fread() and fwrite() where
>> > > the header can be automatically prepended for supported files and/or the
>> > > dbm/flatfile be updated simultaneously.  And while the dbm/flatfile could
>> > > get out of sync, it should be pretty easy to get something like that
>> > > cleaned up fairly painless and easily from cron or something.
>> > > 
>> > 	This is going to be useless on other OSes. Remember, that while
>> 
>> This is absolutely wrong.  I don't know why so many people don't see it. 
>> The assumption is that all GNOME programs will use the GNOME wrappers. 
>> Then, these wrappers can be compiled into their own library.  Then, if you
>> put the GNOME wrapper library in LD_PRELOAD, functions with the same name
>> will be called by the wrapper library instead of the C library, thus
>> making all non-GNOME programs immediately GNOME aware.  This solves the
>> problem of commands like 'mv', 'cp', etc, orphaning object data. 
>
>  I don't want mv cp to be GNOME AWARE !!! I want themn to keep the exact
>same behaviour whether Gnome is installed or not. If this is not the case
>most people WILL NOT USE GNOME, except the couple of "developers" happy of
>their trick.
> 
>> > desktop. Make the assumption even that the user's home directory is NFS
>> > mounted off a SunOS server. Then you will be doing the right thing.
>> 
>> If each end is SunOS, then they'd have to use a modified Linux NFS server
>                                                  ^^^^^^^^^^^^^^^^^^
>       And you expect that Linus will accept this ugly patch for inclusion
>  in the standard kernel ??? No of course, so I would need to run a modified
>  linux kernel for Gnome ? Stop this nonsense now !
>
>> that can send and acknowledge "metadata" bits.  This is unlikely to
>> happen.  But it would be ideal if it did.
>> I'm not suggesting a be-all end-all solution by any means - simply trying
>> to find the ideal.  Why not give Linux an advantage (seamless integration
>> of fs and metadata)?  This is a new OS - *our* OS, with *our* utilitities.
>
>  Ok this is a new Os, YOUR, not mine ! But don't call it Linux ...
>
>> Modify 'find' too to deal with the metadata.
>> 
>> find / -name "*.jpg" \! -metadata Thumbnail: -exec ~/mkthumb {} \;
>
>  Geez, looks like advertizing for MS stuff, blinking but futile :-(
> 
>> > that you cannot easily LD_PRELOAD against that for all OSes, especially when
>> > someone logs into an IRIX machine and manipulates the files from there, and
>> > then comes back to their Solaris GNOME desktop. The linking of the metadata
>> > file is obviously going to be broken. The best you can do is try to handle
>> > that gracefully.
>> 
>> I don't understand ... why would it be broken?  All GNOME applications
>> should be using the GNOME wrappers anyway (link against them either
>> staticly or to ensure they load before libc if that is possible) so the
>> only problem with the metadata is for non-GNOME, non-LD_PRELOAD-able
>> systems.  And these are bigger problems that won't be solved because these
>> programs (mv, cp) will always orphan the data.
>
>  Let's face it, I will absolutely refuse to run Gnome if it forces me to
>run with an LD_PRELOAD. This solution simply doesn't work, there is a bunch
>of statically linked apps on any system, there is also sensible application
>that will broke due to the change of semantic, or due to extra reasons.
>  Define a set of operation for metadata, have your apps call them at the
>proper place, install handler if the metadata are not available, but keep
>the design clean or you will get a very good reason to get Gnome project
>flamed and worse abandoned by the potential users ! 
>
>Daniel
>
>-- 
>Daniel.Veillard@w3.org | W3C  MIT/LCS  NE43-344  | Today's Bookmarks :
>Tel: +1 617 253 5884  | 545 Technology Square   | Linux, WWW, rpm2html,
>Fax: +1 617 258 5999  | Cambridge, MA 02139 USA | badminton, Kaffe,
>http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.
>
>
>-- 
>         To unsubscribe: mail gnome-list-request@gnome.org with 
>                       "unsubscribe" as the Subject.
--
Leareth <leareth@geocities.com>
-- You've got to lose, to know how to win