* Uriel <[EMAIL PROTECTED]> wrote: Hi,
> This is an excellent idea, and one example of where 9P can work as a > language and architecture agnostic application interface. Thanks to the list folks, I've got some libs and examples for writing servlets. :) I'm going to fork out the libs to their own, pkg-config'ed packages. Now I need some client library to access 9p2000 services from userland. The userland applications, ie. mozilla should import that library and acess the services through it. Services be represented by some line of text (ie. an URI). Any suggestion ? > You might want to look into the GSoC project to write an Inferno > plugin for Mozilla, In fact, I do not yet know what Inferno actually is (didn't have the time to try it out yet). Is it something like the Oberon runtime system ? BTW: I don't intend to write any "plugin" for mozilla. I actually want to away from that crap. The destiny is to heavily trim down the mozilla tree and move out as much as possile to generic separate packages. Before I know Plan9, my idea was to move things like bookmarks handling to an separate (plain-C) library. That library should provide an quite generic interface, so it could be used by virtually any browser or similar application. Several storages should be provided by (optional) backends. Traditonal "bookmark.html" and LDAP should be only a few of them. Collaborative bookmarking (which is currently done by mozilla specifc extensions) should also be dropped in there. Now that I learned the simplicity of Plan9, all we need is an cross platform 9P2000 client library and clean model for the bookmark fs. AFAIK IE's and KDE's approaches go some bit in that direction (at least they've got one file per bookmark), but still not far enough. Many people have objections against splitting such things into dozens of micro-files, ie. because not to waste OS resources. With an minimalistic userland 9p2000 client and appropriate servlets, we not just get it down, but also have an very simple interface to support virtally any kind of bookmark storage. Also the trouble of "profile sharing" (in other words: multiple access) would be trivial to solve. Not to mention dozens of other problems this solved. Having a quick look at Mozilla's bookmarks.html. If we want an similar storage with "flat" files, we just need something like this: * the root directory contains some dir "bookmarks", which represents top level bookmark dir. (we dont use / for that to have space for adding other things, ie. query interfaces, later) * an bookmark is just an plain file with some random name and some fixed extension, ".B". (other extensions later could be introduced for other things). inside the bm file we've just lines which look like rfc822 (mail) headers. Non-ascii content is url-encoded. * folders are specially marked subdirs, ie. with ".F" extension. additional metadata could be stored in an "INFO" file, also encoded like the bookmark files. Well that would be all. Mozilla's bookmark handling would be rewritten to just access this hierachy, via the 9p2000 client library. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
