From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2abfc8db078f981044b3f9e69934279d@quanstro.net> References: <2abfc8db078f981044b3f9e69934279d@quanstro.net> Date: Mon, 31 Aug 2009 09:25:36 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Interested in improving networking in Plan 9 Topicbox-Message-UUID: 5d101ea0-ead5-11e9-9d60-3106f5b1d025 On Mon, Aug 31, 2009 at 9:04 AM, erik quanstrom wrot= e: > > given the database=3D 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. =A0When 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