Re: [9fans] Interested in improving networking in Plan 9

[erik quanstrom <quanstro@quanstro.net>]

> >
> > given the database= option, if one could confine rapid changes to
> > smaller files, one could teach ndb to only reread changed files.
> >
>
> Why not have a synthetic file system interface to ndb that allows it
> to update its own files?  I think this is my primary problem.
> Granular modification to static files is a PITA to manage -- we should
> be using synthetic file system interfaces to to help manage and gate
> modifications.  Most of the services I have in mind may be transient
> and task specific, so there are elements of scope to consider and you
> may not want to write anything out to static storage.

i can see in principle how this could be a good idea (no more
comments, though).  could you elaborate, though.  i have found
editing /lib/ndb/local works well at the scales i see.

i also don't know what you mean by "transient, task specific services".
i can only think of things like ramfs or cdfs.  but they live in my
namespace so ndb doesn't enter into the picture.

could you give an example?

> When I publish a service, in the Plan 9 case primarily by exporting a
> synthetic file system.  I shouldn't have to have static configuration
> for file servers, it should be much more fluid.  I'm not arguing for a
> microsoft style registry -- but the network discovery environment on
> MacOSX is much nicer than what we have today within Plan 9.  An even
> better example is the environment on the OLPC, where many of the
> applications are implicitly networked and share resources based on
> Zeroconf pub/sub interfaces.

sounds interesting.  but i don't understand what you're talking about
exactly.  maybe you're thinking that cpu could be rigged so that
cpu with no host specifier would be equivalent to cpu -h '$boredcpu'
where '$boredcpu' would be determined by cs via dynamic mapping?
or am i just confused?

- erik