[9fans] Taking plan9 concepts to *nix

[9fans] Taking plan9 concepts to *nix

[Enrico Weigelt]

Hi folks,


I'd like to take some concepts of plan9 (ie. running servlets via
9P2000) to unix and other platforms.

One contineously headache-causing application is Mozilla. It had
become too fat, quite unmaintainable, indeterministic and often
hanging. There's an project called nspluginwrapper which runs
plugins in it's own process (invented to get binary crap like
flash or acroread running on non-x86_32 platforms). For now it
uses an (undocumened) unix-socket protocol for communication
between browser and external plugin. Seems like a good starting
point for showing the power of 9P2000 to the wide world ;-P

The idea is: the browser exports an fs with the standard plan9
graphical window and some additional (browser-specific) services.
So from the view of the "plugin" (which now becomes an separate
application), it's place in the browser is an graphical terminal
with perhaps some additional features.

I'm not yet confident enough w/ 9p programming and seeking for
help. Would anylone like to help me ?


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/
---------------------------------------------------------------------

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

[Uriel]

This is an excellent idea, and one example of where 9P can work as a
language and architecture agnostic application interface.

You might want to look into the GSoC project to write an Inferno
plugin for Mozilla, I am afraid it doesn't have its own page in
http://gsoc.cat-v.org/projects/ yet, but bnext has posted about it in
the blog http://gsoc.cat-v.org/blog/ and he was discussing his work in
#plan9-gsoc just yesterday, so you might want to join and talk with
him about some coordination.

Best wishes

uriel

On 6/28/07, Enrico Weigelt <weigelt@metux.de> wrote:
>
> Hi folks,
>
>
> I'd like to take some concepts of plan9 (ie. running servlets via
> 9P2000) to unix and other platforms.
>
> One contineously headache-causing application is Mozilla. It had
> become too fat, quite unmaintainable, indeterministic and often
> hanging. There's an project called nspluginwrapper which runs
> plugins in it's own process (invented to get binary crap like
> flash or acroread running on non-x86_32 platforms). For now it
> uses an (undocumened) unix-socket protocol for communication
> between browser and external plugin. Seems like a good starting
> point for showing the power of 9P2000 to the wide world ;-P
>
> The idea is: the browser exports an fs with the standard plan9
> graphical window and some additional (browser-specific) services.
> So from the view of the "plugin" (which now becomes an separate
> application), it's place in the browser is an graphical terminal
> with perhaps some additional features.
>
> I'm not yet confident enough w/ 9p programming and seeking for
> help. Would anylone like to help me ?
>
>
> 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/
> ---------------------------------------------------------------------
>

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

[Enrico Weigelt]

* 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/
---------------------------------------------------------------------

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

[Roman Shaposhnik]

Hi

On Thu, 2007-06-28 at 20:32 +0200, Enrico Weigelt wrote:
> 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.

  To me, the biggest advantage of the architecture you seem to have
in mind is that it becomes extra easy to access and manipulate those
objects (e.g. bookmarks, visited pages, etc.) from outside of the
Mozilla. Grepping through the recently visited pages seems to be
quite useful at times.

Thanks,
Roman.

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

[Enrico Weigelt]

* Roman Shaposhnik <rvs@sun.com> wrote:

Hi,

> To me, the biggest advantage of the architecture you seem to have
> in mind is that it becomes extra easy to access and manipulate
> those objects (e.g. bookmarks, visited pages, etc.) from outside
> of the Mozilla.

Yep. That's one side of the story: using some universal storage
and integrating with lots of other applications or sharing between
several instances over the net will be quite trivial.

The oder side is simplicity: Mozilla really suffers from quite
unmaintainable code. Nobody really sees through, and the whole
blob is nearly undebuggable. People invent really sick "solutions"
to non-problems (ie. the mork "database"-format) and avoid really
necessary radical cleanups / refactoring.

My first plan (back several years) was to move out one thing by
another into separate (mozilla independent!) libs. This of course
would work, but compared with the simplicity of an virtual fs
it's just a waste of resources. With an clean and simple model,
the fs can handle 90% of the tasks by itself, and from that point
we can do all these nice things which can be done with an fs
(ie. sharing over the net).

Mozilla folks are working on other solutions which were meant to
go in a similar direction (ie. generalized db api, mork, sqlite)
for quite a long time (AFIAK in FF 3.x, sqlite should be standard),
but they all are additional features, the old crap will still be
carried for a long time. I really wonder, how they can seriously
think about embedded targets in such an sitation ;-O


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/
---------------------------------------------------------------------

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

[Roman Shaposhnick]

On Thu, 2007-06-28 at 15:29 +0200, Enrico Weigelt wrote:
> The idea is: the browser exports an fs with the standard plan9
> graphical window and some additional (browser-specific) services.
> So from the view of the "plugin" (which now becomes an separate
> application), it's place in the browser is an graphical terminal
> with perhaps some additional features.

  You should really take a look at Plan B work that Nemo's team
has been doing:
   http://lsub.org/ls/planb.html

Thanks,
Roman.

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

[Francisco J Ballesteros]

There are several things that we are not going to implement soon, that
any other one
could take, should it be interesting.

One is to implement other viewers for omero (in Inferno), so that a
different kind of
feel (eg., one for non-programmers) could be available.

Another one is to write a unix library compatible with a popular
widget interface, but
running against omero instead of using X. That way, unix apps using
that inferface could
exploit both inferno and omero.

There are more ideas, but we're quite busy right now with the octopus
in general.
In particular, omero for the octopus and a silly paper is getting 90%
of my time.

Thought I should say this, just in case :)


On 6/28/07, Roman Shaposhnick <rvs@sun.com> wrote:
> On Thu, 2007-06-28 at 15:29 +0200, Enrico Weigelt wrote:
> > The idea is: the browser exports an fs with the standard plan9
> > graphical window and some additional (browser-specific) services.
> > So from the view of the "plugin" (which now becomes an separate
> > application), it's place in the browser is an graphical terminal
> > with perhaps some additional features.
>
>   You should really take a look at Plan B work that Nemo's team
> has been doing:
>    http://lsub.org/ls/planb.html
>
> Thanks,
> Roman.
>
>