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 <weig...@metux.de> wrote: > * Gastón Tonietti <gaston.tonie...@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: weig...@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 >
_______________________________________________ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
