Re: [9fans] Taking plan9 concepts to *nix

[Enrico Weigelt <weigelt@metux.de>]

* Uriel <uriel99@gmail.com> 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/
---------------------------------------------------------------------