Re: NautilusMetadata

["Nickolay V. Shmyrev" <nshmyrev yandex ru>]

В Птн, 22/04/2005 в 11:59 +0200, Alexander Larsson пишет:
> On Sun, 2005-04-10 at 14:18 +0200, Diego Gonzalez wrote:
> > Is there any reason to keep all the nautilus metadata related
> > functionality using Bonobo. 
> > Can i remove the bonobo use from those objets and turn them normal
> > GObjects?
> > 
> > I have been looking at it and this is what i will try:
> >    1) Remove all the bonobo usage from nautilus-metafile.c and
> > nautilus-metafile-factory.c
> >    2) Remove all the monitor classes related to metadata and convert
> > the NautilusMetafile to emit signals instead
> >    3) Remove nautilus-directory-metafile and adapt all the classes to
> > call directly the nautilus_metafile methods.
> > 
> > I think i can have this working in a couple of weeks if there is
> > interest in it.
> 
> It was historically done because nautilus was a multi-process system,
> with components in various processes. If any process wanted to update
> some metadata it told the main process to update it which in turn
> updated all other processes.
> 
> We don't really use out-of-process components anymore though, so maybe
> we can get rid of this. 
> 
> I have one main concern though. Long-term we really want a metadata
> system for files that is public, and that other apps can use. This means
> that such a system must use some form of IPC to allow updates to get
> propagated from a master metadata handler (while at the same time you
> need high performance access to metadata, at least in nautilus).

There are several bug filled against evince with request about spatial
behaviour, 
also I think similar bugs can be filled against many applications. We
need
to remember document zoom, size, document position, searched text. We
need thumbnails and so.  GEdit as I know uses similar metadata system
with per-document properties like in GConf. So this is not future but
immediate task.

> 
> Its clear that the current internal Bonobo/Corba API is not the one that
> would be used for a new public metadata system. The question is, is it
> worth changing the current system (maybe causing some destabilization)
> to an in-process system, knowing that long term we might replace it.
> 

The performance is not an issue here. It will be slow with any IPC. The
way to solve it in nautilus is to allow per-directory queries like that

metadata_daemon_get_metadata_for_every_file_in_dir()

Anyhow it's not the real question. We can use DBus or Bonobo or any IPC
you like. 
Gnome-vfs-daemon uses ORBit, GConf uses ORBit, why not use it.

> I think its worth it. It would be nice to clean up the current code,
> removing all the hard-to-read corba cruft in it, while keeping the main
> structure. This will make the code a lot easier to read and understand.
> 

It is not so hard to implement metadata framework and it will be _very_
useful. So why should we do work twice first removing old code and the
removing new one? 

Alex, can you describe the requirements to such framework and how do you
see it's organization. Then we can create some proposal and start with
it's implementation.