On Mon, Aug 31, 2009 at 9:04 AM, erik quanstrom<quans...@quanstro.net> wrote:
>
> 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.
>> registration/discovery mechanism to existing applications. When I
>> export, a flag should make that export visible to zeroconf resolution,
>> etc.
>
> what do you mean by export?
>
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.
-eric
