-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 07, 1999 10:46 AM To: [EMAIL PROTECTED] Subject: BOUNCE [EMAIL PROTECTED]: Non-member submission from ["Mike Fletcher" <[EMAIL PROTECTED]>] >From [EMAIL PROTECTED] Thu Oct 7 10:46:03 1999 Received: from vrtmail.robocity (vrtmail.vrtelecom.com [209.195.170.44]) by ariadne.iz.net (8.8.7/8.8.7) with ESMTP id KAA25611 for <[EMAIL PROTECTED]>; Thu, 7 Oct 1999 10:46:02 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from cr706570a (cr706570-a.yec1.on.wave.home.com [24.112.128.169]) by vrtmail.robocity with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 4DFA2B7W; Thu, 7 Oct 1999 13:36:50 -0400 From: "Mike Fletcher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: Re: Persistence and server record models Date: Thu, 7 Oct 1999 13:47:43 -0400 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <[EMAIL PROTECTED]> Importance: Normal >> From the (Fruits of/Core) Living Worlds camps... Most systems use either a scanning or registration approach: Registration: Living Worlds, Core Living Worlds and Fruits of Living Worlds use a root node from which the software builds a "multi-user graph", which contains all of the multi-user (and therefore all of the persistent and especially serviced) properties of the vrml sceneGraph. This multi-user graph structure is communicated to the server (along with where to get the static source) by the author's system at creation/adding time. In the abstract, any given node in the multi-user graph may have associated with it a "description", which in most cases is the URI of the source code, as well as some number of "data points" (states)[1]. To ensure that the state of the sceneGraph is consistent with the stored state, it is necessary only to send the "description" and values of all data points (states). Because there is a single registrar (Living Worlds provide the concept of multiple zones, but this has never been implemented to my knowledge), or a set of known registrars, the structure is very easily resolved into record IDs.[2] That is, the creator enters a set of records in the database which contains the "description" and the list of "data points". All others connecting to the database retrieve both the description and the data points from the database, applying the latter to the former. The content creator is responsible for ensuring that the content will be able to handle non-ordered update among different data points (i.e. State1 and State2 might come in in any order, so you cannot use the one to initialize the other). In practice, this has not proved to be a significant limitation. Scanning: The Fruits of Living Worlds allows for (but does not require) a more opportunistic model, where the entire sceneGraph may be scanned for potential "multi-user graphs", and any of the these may be registered with the database. The key is abstracting somewhat from the original Living Worlds proposal to create a world-level record. All multi-user graphs which are discovered within a loaded set of nodes are conceptually parented to this world-level record (i.e. their root namespace is one (compound) record, and they are stored as such (by implication, they must have unique names within that namespace (not generally a problem, as they're normally authored by a single entity))). Enjoy yourselves, Mike [1] In Living Worlds and Core Living Worlds, this description is only mentioned in relation to the SharedObject. [2] My understanding is that this is Blaxxun's strategy as well, with their BlaxxunZone nodes. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: October 7, 1999 11:49 AM To: Jeff Sonstein Cc: steve guynup; [EMAIL PROTECTED] Subject: RE: soon to be developing again I would like to say yes, they are completely solved -- =) More to reality - I worked through some of them when I built my test system, which I am happy to share, there tend to still be some unresolved issues, primarily in that the more that is done to solve persistency the more integration need between the VRML scene file and the datbase records need to exist. The problem will be (and maybe it is not a problem) but I see a need to build a **something** that can make sure that the VRML file and the database record match - maybe this is the user that is building the world, or maybe it is in the software, I dunno... THoughts ? -A Andrew Phelps Department of Information Technology Rochester Institute of Technology http://www..it.rit.edu/ http://andysgi.rit.edu/ On Thu, 7 Oct 1999, Jeff Sonstein wrote: > > If these issues of persistence are worked through [...] > > and I think they shall be... > > jeffs > > -- > Jeff Sonstein, M.A. http://ariadne.iz.net/ > http://ariadne.iz.net/~jeffs/jeffs.asc > ============================================== > there are no bugs > there are just undocumented features > >
