Re: Lazy behavior in Extfs



Nice. It should be very useful to handle it this way. Is there any issue for tracking this improvement or we should open a new one?

On Mon, Sep 13, 2010 at 7:06 PM, Enrico Weigelt <weigelt metux de> wrote:
* Gastón Tonietti <gaston tonietti gmail com> schrieb:

> I'm in the process of creating a custom extfs for a special file type, and I
> was researching in the existing scripts to  get some examples. I was able to
> start doing some listings. But then I figured out that for all scripts mc
> calls them just once and they provide the full content for the entire file,
> and it seems mc parses the list using the "/" so it knows all the structure
> and it never invokes the script again.

That's IMHO a generic design problem in extfs, as it handles only
whole archives. This also tends to cause trouble if the archive
changes w/o extfs noticing it (I often have this case w/ patchfiles).

A clean solution, IMHO would be putting these things into little
fileservers, which directly provide the filesystem operations
and internally do whatever's optimal for the actual archive type.
(doing this as separate fileservers, eg. via 9P, instead of extending
mc-vfs, allows them to be independent from mc itself and usable w/o it.)

Actually I need to do some heavy initialization stuff when opening the archive, and suppose the laziness issues for Extfs is solved, the initialization stuff will be done many times, each time MC hits the script with different internal path.

The desired behavior should be to work with a single instance of the *service* for the given archive and keep it during all the MC session. This way all initialization work is done just once, the ideal scenario for LAZY processing. Also the *service* could listen for external changes made to the archive and ask MC for a refresh some way.

Gaston.


> So I was wandering if it is possible for mc to fetch content from extfs
> script in a lazy way. The first time I return the list at the root level,
> then when mc wants to enter in some of the entries it hits the script again
> with the file path plus the relative internal path. This way only the needed
> part of the file is loaded.

This would change semantics of the extfs interface, actually making
these scripts little fileservers, in this case non-persistent ones
(a bit like an kind of nfs or dav via command line ;-)).


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt metux de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]