Re: [Nautilus-list] Icon directory contents caching

[Maciej Stachowiak <mjs noisehavoc org>]

On 15Oct2001 02:42PM (-0700), Ian McKellar wrote:
> On Sun, 2001-10-07 at 22:17, Darin Adler wrote:
> > So gnome-vfs would get monitoring first (I am still hoping for gnome 2.0),
> > then metadata next, then calls to locate appropriate icons for files (with
> > icon themes presumably being part of that).
> 
> There is some monitoring support in GnomeVFS HEAD. It seems to work for
> file:// uris and I haven't implemented support for any other scheme. I
> don't think I designed the API right or implemented it well so the
> implementation and the module API might change before GNOME 2.0, but the
> application API should stay the same.
> 

I looked over the code some and thought about the issues, and here is
my proposal for revising the design.

In principle, the gnome-vfs sync API should not introduce a dependency
on the glib main loop, and the module operations should count on the
job mechanism to handle asynchronicity


GnomeVFSResult gnome_vfs_monitor_new (GnomeVFSMonitor **monitor,
				      const char *uri,
				      GnomeVFSMonitorType monitor_type,
				      GnomeVFSMonitorEventType events) 

/* Creates a new monitor object. Last argument is an OR mask of
   event types you care about. */

void gnome_vfs_monitor_ref (GnomeVFSMonitor *monitor);
void gnome_vfs_monitor_unref (GnomeVFSMonitor *monitor);

int gnome_vfs_monitor_get_fd (GnomeVFSMonitor *monitor);

/* gives you a file descriptor so you can wait for an event in your
   own poll or select loop. */

GnomeVFSResult gnome_vfs_monitor_get_next_event (GnomeVFSMonitor *monitor,
						 GnomeVFSEventType *type,
						 char **event_uri);

/* Gets the next event available from the monitor handle. Should
   probably be nonblocking since it may be no events for this handle
   are available if multiple monitors share one fd. */

GnomeVFSResult gnome_vfs_monitor_stop (GnomeVFSMonitor *monitor);

/* Stop monitoring. Dropping the last ref should also stop
   monitoring. */


One down side to this, though, is that every monitoring implementation
would _have_ to give you a file descriptor you can wait on - it
_can't_ just rely on periodic active polling on a separate
thread. This means that you'd need a monitoring daemon for any module
that wants to implement monitoring by polling.

On the other hand, with the async API, or even for some apps that use
mostly sync I/O but use the glib main loop, you just want one call
that lets you set up a monitor and wait for callbacks.

That can look somewhat like the current gnome_vfs_monitor_add/cancel
(though it should be async_monitor_add/remove), but the callback needs
an extra GnomeVFSResult argument to report errors setting up the
monitor or while monitoring. It could also use a regular async handle,
but I'm not sure if this is the right approach (there's no job thread
to be cancelled, just an I/O callback). 

It can be implemented from the above primitives by doing the monitor
setup asynchronously in a thread and hooking into the main loop with a
GIOChannel.

Ian, what do you think of this proposal? If you like it, which of us
would you prefer to do the changes?

 - Maciej

P.S. Metadata support in gnome-vfs is a major 2.2 goal, I hope someone
starts on it soon.