Re: [vos-d] [x3d-public] Re: Wham! SMAM! Avatar Jam!
On 06/05/07, Tommi Laukkanen <[EMAIL PROTECTED]> wrote: Hi Sounds like a good plan. Regarding the avatar movement streaming protocol we could consider it to be part of the web3d analogy to HTTP (traditional web). X3D documents i.e. the static scene can be transfered to client browsers using HTTP but the three dimensional web raises intuitively new requirements namely avatars and interaction. Yes, that is a good analogy. My personal opinion is that not many people are really interested in interlinked 3d models without human interaction. Very good point. A phd student I spoke to said: "It will be much better if there is some form of conversation." He went on to outline a v simple form of conversation where avatars tow around a thumbnail list of their favourite pics. if u click on the thumbs u get the image. Avatars of attendees could show their favourite SIGGRAPH pics. Those not attending may show their pets/whatever. They would have a tab to click on to unroll the thumbs. Avatar movements and object dynamics need to be synchronized between browsers and servers to enable distributed interactive simulation. There was some interesting work already done in the DIS-working group but the final protocol could be slightly less application specific. SWaMP could also be even perfect candidate for the standard but I have not been lucky enough to get to see the specification yet. yes I'm hoping to try out SWaMP. And there is XOM for the server comms to look at. The protocol could be called something like scene synchronization protocol (SSP) or X3D scene synchronization protocol XSSP. In addition to scene synchronization protocol some message contracts for login/logout, avatar selection and avatar control (in case the avatar scripting is run at server side ) would be well worth the effort. I am eager to dedicate my time and server resources to the work at hand. That's great Tommi. I will be putting out a request for help in each area, with all the info I have gathered in the online "blat" document. cheers, chris best regards, Tommi Laukkanen http://questforvr.blogspot.com On 5/5/07, chris < [EMAIL PROTECTED]> wrote: > > For this event OTTOMH, here is a first cut at things that have to be > accomplished: > > I will use the headings as an outline to this document: http://www.planet-earth.org/sg07/SMAM07.html > > where I'll just start blatting information to as I find it. > > 1. May > 1.1 Find/allocate some servers for prototyping. > 1.2 Collect together a set of public avatars to use and test them (we > want to ensure there are no scripts that would bog a client down and they > all basically work). > 1.3 Work out a simple protocol for streaming avatar movements over > tcp/ip or udp (or both). Since MediaMachines have a demonstrated prototype > protocol (SWaMP), implemented on Flux: , that would be a good place to > start. > 1.4 Choose one or more server software components to test client-server > comms and server-server comms. > 1.5 Choose some client software to run tests on. > 1.6 Run server-server tests and client-server tests. This will be to > shake out the various tools / technologies we have to choose from. > 1.7 Analysis, planning next month. > 1.8 Organise booth(s) at siggraph show floor. My company (Systemic) is > putting some money in, what about yours? > 1.9 UI for login and avatar selection. > > 2. June > > 2.1 First single server-client multiple avatar tests. There will > probably be multiple isolated tests like this. > 2.2 User interface tests. > 2.3 Client interaction tests. > 2.4 Second single server-client mass avatar tests. There will probably > be multiple isolated tests like this. > 2.5 Analysis. > 2.6 Planning for July. > > 3. July > > 3.1 First serious test of mass avatar collaboration at a selected hour. > 3.2 Second serious test of mass avatar collaboration at a selected hour. > 3.3 Analysis. > 3.4 Planning for the conference. > > 4. August > > 4.1 Conference demonstration 5th-8th. > 4.2 MUVEW Networking BOF (Thursday 10:30-12:30). > > Anything else?, > > regards, > > chris > > -- > http://www.planet-earth.org > http://ping.com.au > http://systemic.com.au > http://planet-earth.org/Rez/RezIndex.html > -- > It be a great secret: there be more truth at the centre. > -- http://www.planet-earth.org http://ping.com.au http://systemic.com.au http://planet-earth.org/Rez/RezIndex.html -- It be a great secret: there be more truth at the centre. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
I don't think Jacobson was suggesting that a really new paradigm in networking would be able to handle the robust case of broadcast data, of which unicasting is simply a subset. I find you need a little creativity to fill in some of the gaps in the later part of the talk, since he wasn't presenting a design (or really, even a complete theoretical architechture) but simply some big ideas that he thought were worth a lot more attention. Packet switched networks are fine for realtime communication, provided there is enough bandwidth and they arn't congested. That performance degrades rather than simply shutting down and/or denying new connections is a feature, not a bug. As you point out, no existing system adequately fufills the requirements of online virtual worlds which precisely why we've spent so much time building our own. The problem is a curious mix of large quantities of mostly static data (3D models, textures) punctuated by dynamic data with high frequency changes and requirements for low latency. Throw in streaming media to the mix (voice) and it's really an architechtural nightmare when you consider the vast majority of network research has been in trying to solve each of these problems in isolation and to the exclusion of the others. The reason broadcast routing is so exciting is that we're not just trying to solve how to move the latency-sensitive high-frequency bits around, but that distributing and caching static resources (geometry, textures) is a huge part of the problem, and one that we never adequately addressed in the current/old s4 design. Indeed, moving the latency-sensitive high-frequency bits around is easy, because there isn't that much of it, and the problem was largely solved by online games ten years ago. On Wed, May 09, 2007 at 12:10:16PM -0700, dan miller wrote: > Hi -- > > I'm new to the list though I have been on IRC now & then. > > I loved Jacobson's talk but one point struck me: the introduction of a new > paradigm doesn't obviate the need for the old. Packet-switching is great > for fault-tolerance when the goal is "get this packet from here to there, no > matter what." It's actually the postal paradigm (thru wind & sleet...) > > But the old telco real-time, hard-wired point-to-point connection was > actually better suited to some things we do today over packet networks, > particularly teleconferencing. The control over latency and timing is lost > when you switch to TCP (as you VOS folks know only too well). > > A data subscription model is really just a cool technological way to > introduce the concept of publishing to the digital world in a useful way; > but it doesn't change the fact that packet-switched networks are not so > great for realtime communication. > > WRT VOS/Interreality goals, in particular avatar/object behavior (whether > scripted or resulting from user input), we have a mix of requirements that > doesn't easily fit any model I'm aware of. It's time critical, like a phone > conversation; it's point-to-many-point, like publishing; it's ephemeral, > like broadcasting; but it's not fully global, in that typically you only > care about a few objects in your virtual vicinity. Distributing this data > liberally is not an option due to bandwidth. > > The bittorrent model doesn't really wash here because of the requirement for > low latenc. I think in this case we have another animal entirely, which is > basically a secure multipoint channel cluster. The closest analogy I'm > aware of would be multi-party teleconferencing. AT&T actually does this > pretty well. > > This animal should be optimized for its intended use, and not shoe-horned > into paradigms that it doesn't really fit. It might be reasonable to take a > look at some of the ITU work in this area, such as H.323, and even the IETF > VOIP/SIP stuff that's out there. > > I'm not saying we should necessarily adopt any such standards; but it is > often worthwhile to take a good look at how similar problems have been > tackled, for better or worse. Otherwise you risk spending mucho time > reinventing various types of wheels. > > -dbm -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] delineation and revision control
Let's see if I can clear up a few things... Bear in mind that the design is still evolving in my head :-) a) From the perspective of VOS, which is concerned with synchronization, the most important purpose of versioning is so you have a basis for deciding whether your replica A' of vobject A is current or out of date. Being able to record changes and go back into the history is just a nice side effect. b) Each vobject would be versioned separately. The child list is part of the versioned state, but a change to a child vobject should not affect the version of the parent. One exception: embedded children (property fields) do affect the version. c) The big picture I'm going towards here is that remote vobjects, caching, scalability/load balancing and the kind of broadcast routing Van Jacobson talks about are all basically cases of replication. If the VOS design can unify these cases under one general solution then we've won. I need to develop the idea more, but I think one key idea is relaxing the idea of a "site" so that it doesn't have to be tied to a specific host. I had already decided that sites would be identified by their public key, so that messages distributed by the site are self-verifying (by checking that the digital signature matches the site id). This means if you want to query a vobject, any replication -- the actual host site, a local cache, a third party -- can answer, and you can check that the answer did in fact originate from the site. What's really interesting is that this means the authority to publish changes to vobjects rests in who has knowledge of the private key that corresponds to the site's public key. If you wanted to do load balancing/clustering, you could share that private key among several trusted hosts, any one of which would be able to issue official state changes for vobjects on that site. I should point out that in the most common case, hosts will be in direct contact with the actual site, and receive messages published from the site directly, so it's not any different from the way things work now. Getting back to Kao's question (which I've wandered quite far away from), as noted the synchronization principals in the system are the site and individual vobjects. I don't see how cycles and bounderies between subgraphs factor into it, except perhaps in the initial phase of determining the specific subset of vobjects on the site you're interested in. On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote: > Well, Lars' suggestion of versioning only "interesting" parts and > your suggestion of horizons seem reasonable, but I don't think we > have the basis for this in VOS. A vobject usually cannot live as > isolated entity, but *requires* a number of relations to child > vobjects to make sense; thus any user-percievable "world object" is > actually a subgraph of the overall world graph. > > The problem is delineation: It is not clear which subgraphs represent > independent "world objects", or if there is even a distinctive > decomposition. For example, two objecs may share a texture - which > vobject does it "belong" to? If you change one vobject, do you > include the texture in the version? Where do you stop following > relational links? I don't recall if there is any prohibition in VOS > against cycles in the graph - I think there isn't - so matters become > even more complicated. > > The only separation I currently see in VOS is the relation between > the site vobject and its children, but even here it is not clear > which children represent aspects of the site itself, which are > scenery, and which are avatars. > > Any suggestions? > > Regards, > Karsten Otto (kao) > > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
Hi -- I'm new to the list though I have been on IRC now & then. I loved Jacobson's talk but one point struck me: the introduction of a new paradigm doesn't obviate the need for the old. Packet-switching is great for fault-tolerance when the goal is "get this packet from here to there, no matter what." It's actually the postal paradigm (thru wind & sleet...) But the old telco real-time, hard-wired point-to-point connection was actually better suited to some things we do today over packet networks, particularly teleconferencing. The control over latency and timing is lost when you switch to TCP (as you VOS folks know only too well). A data subscription model is really just a cool technological way to introduce the concept of publishing to the digital world in a useful way; but it doesn't change the fact that packet-switched networks are not so great for realtime communication. WRT VOS/Interreality goals, in particular avatar/object behavior (whether scripted or resulting from user input), we have a mix of requirements that doesn't easily fit any model I'm aware of. It's time critical, like a phone conversation; it's point-to-many-point, like publishing; it's ephemeral, like broadcasting; but it's not fully global, in that typically you only care about a few objects in your virtual vicinity. Distributing this data liberally is not an option due to bandwidth. The bittorrent model doesn't really wash here because of the requirement for low latenc. I think in this case we have another animal entirely, which is basically a secure multipoint channel cluster. The closest analogy I'm aware of would be multi-party teleconferencing. AT&T actually does this pretty well. This animal should be optimized for its intended use, and not shoe-horned into paradigms that it doesn't really fit. It might be reasonable to take a look at some of the ITU work in this area, such as H.323, and even the IETF VOIP/SIP stuff that's out there. I'm not saying we should necessarily adopt any such standards; but it is often worthwhile to take a good look at how similar problems have been tackled, for better or worse. Otherwise you risk spending mucho time reinventing various types of wheels. -dbm ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
Lalo Martins wrote: > On Wed, 09 May 2007 09:07:57 +0200, Karsten Otto wrote: > > I don't quite understand what you need versioning for. The bulk of > > changes you get in a shared word is avatar movement, which may wind up > > to ~30 changes per second per avatar. Do you really want to keep a > > record of all this? My understanding was that if you want to make a > > movie, its your responsibility to do the recording (and filling your > > hard disk), not that of the world/server. > > IMO, much of the "interesting" content may not actually be 3d objects, > but rather, information (text, models, images, sound, the works) which > you use the 3d objects to navigate trough and interact with. > > Anyway, in my mental model, the answer to that is horizons. For a > document (akin to a wikipage), you may define an infinite horizon: all > revisions will be kept. For most 3d content, the default horizon, which > is to be defined -- a month, a week, 200 revisions? And for things like > position of avatars, zero: no revision control at all. > > Alternatively, only record a revision when the object remains unchanged > for some period of time... but this is hairy to implement and I'm not > sure it would be worth it. > You could approximate this by taking revision snapshots at specified intervals in time, as long as the object has changed at least once in that interval (or at least n times, maybe). That way you may not get every revision, but you could at least have one every hour or every day. You'd want this for complex objects that change often, but for which not every change is necessarily critical to remember. Another use for that might be recording animations -- store object movement 10 times a second or something. Though "animation" has a slightly different meaning than "revision history" -- you can have several different "animations" stored for the same group of objects, and only care about the relative ordering and timing within each animation, whereas revision history generally has only one thread with absolute ordering and timing. So animation could be generalization of revision history -- an animation is a series of object states ordered and timestamped (with a relative or absolute time) -- whereas a revision history is one particular series of object states with absolute timestamps. An object can have several animations associated with it, but only *one* revision history. The revision history can even store version changes for other animations in the object, but you wouldn't want it to store version changes for itself :) Addressing a previous version could be something like vip:://hostsite/my/revisioned/vobject/version/5 -- where "version" is a reserved contextual name that specifies an object's revision history (so maybe call it "core:version"? or "history:version"?) Animations would be similar: vip:://hostsite/my/animated/vobject/happyfunanimation/6 -- but have any name you want. Then of course you could have vip:://hostsite/my/animated/vobject/version/2/happyfunanimation/8 if the animated object is also revisioned :) (Actually, getting to the object might be more like vip:://hostsite/my/revisioned/vobject/version/5/object -- this way you can store metadata at the revision node, such as vip:://hostsite/my/revisioned/vobject/version/5/timestamp. And you can store data at the animation node, too, such as vip:://hostsite/my/animated/vobject/happyfunanimation/loopmode) Like I said in another email, when you store a revision of an object, you change its links to point to the correct revisions of all its child objects, too, therefore maintaining the integrity of the tree. As long as its child objects are versioned, that is. Just one possible implementation, of course! -Ken ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] delineation and revision control
A simple solution to this might be to just store the revision number of each child object in the stored revision of the parent object. So if you had three objects, two of which shared a child, like this: A (revision 4) child C B (revision 2) child C C (revision 5) (previous revisions removed for clarity) Then A got changed, you would have this: A (revision 5) child C A (revision 4) child C (revision 5) B (revision 2) child C C (revision 5) If no revision specifier exists, the latest version is assumed. Then, if C gets updated, B will correctly point to the latest version, but the integrety of A will remain as it will still point to its older version. (You could also have a flag or an option or a built-in-metaobject-behavior or something that specifies that certain children *always* point to the latest object instead of remembering their versions at the time of parent-versioning.) This way, you don't have to keep unnecessary copies around as long as the children are already versioned. -Ken - Original Message - From: "Reed Hedges" <[EMAIL PROTECTED]> To: "VOS Discussion" Sent: Wednesday, May 09, 2007 5:07 AM Subject: Re: [vos-d] delineation and revision control > > Yes, only some things would be versioned, or have different policies as > Lalo suggests. > > Yes, child linking has to be preserved correctly. I think we can > basically take an object's child list as part of its state. When you > make a new version you might change those, or copy them whole from the > original. In your example, the texture belongs to both I guess, but > really, both objects have links/references to some objects, that it > just happens to be the same one can be looked over for the most part I > think. > > Reed > > > > On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote: > > Well, Lars' suggestion of versioning only "interesting" parts and > > your suggestion of horizons seem reasonable, but I don't think we > > have the basis for this in VOS. A vobject usually cannot live as > > isolated entity, but *requires* a number of relations to child > > vobjects to make sense; thus any user-percievable "world object" is > > actually a subgraph of the overall world graph. > > > > The problem is delineation: It is not clear which subgraphs represent > > independent "world objects", or if there is even a distinctive > > decomposition. For example, two objecs may share a texture - which > > vobject does it "belong" to? If you change one vobject, do you > > include the texture in the version? Where do you stop following > > relational links? I don't recall if there is any prohibition in VOS > > against cycles in the graph - I think there isn't - so matters become > > even more complicated. > > > > The only separation I currently see in VOS is the relation between > > the site vobject and its children, but even here it is not clear > > which children represent aspects of the site itself, which are > > scenery, and which are avatars. > > > > Any suggestions? > > > > Regards, > > Karsten Otto (kao) > > > > > > ___ > > vos-d mailing list > > vos-d@interreality.org > > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data"
You put your finger on the major issue: cost. The energy budget is a part of the noise factor of any communications network, artificial or organized. The web is predated by better designs with regards to noise and is a bit of a botch with respect to quality in terms of how it has been marketed. No surprise there because quite a bit of the technological infrastructure in use today is marketed that way with the marketing goals dominating the feedback to the design goals. The orthogonal pressure of investing schemes such as hedge funds, private equity, venture capital etc. drive the quality down further because the squeeze for numbers if not met by innovation come out of the employees and other aspects of corporate management. Predictions that the network models such as the web would lead to this were made prior to the web tsunami not because of the web in particular although it is a particularly bad case, but because the laws of second order cybernetics and complexity indicate this will be the case. I use examples such as the questions on the blog simply to point out that even for what some would consider cultural memory with a very high penetration of exposure for some spatio-temporal event, the distortion effect of a high intensity noisy signal over a much shorter time at a higher bandwidth is sufficient to degrade the reliability of any copy. The cost of purchasing a vetted copy of the series, watching the first episode (sufficient to answer all of the questions correctly therefore to pass a single test of the reliability of the source) is quite minimal. The cost to correct the damage across the culture is not. So while the value of that particular corpus may not significant, it is easily demonstrated the modulation of frequency and amplitude for a signal of high impact is sufficient to distort a high value decision. Again, the first three pages of Shannon's seminal work provides the basic model of selectors (decision trees). To apply the model socially, behavioral science is a sufficient model. To figure these into a hypermedia system design that can adapt to distortion or to create distortion, a second order cybernetic model is a good start plus some study into signal filtering models. The web isn't actually designed to be dirty. It designed not to care if it is dirty or clean. It is a minimalist contract much the way a virus is a minimalist interface for propagation without regard to host degradation. The web doesn't care. You have to. That's the deal. len -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars O. Grobe Sent: Wednesday, May 09, 2007 2:39 AM To: VOS Discussion Subject: Re: [vos-d] Van Jacobson: "named data" > In effect, regardless of the wrapper, unless you have the original 1959 > first episode of Rocky and Bullwinkle, you probably can't answer those > trivia question correctly. There are some approaches to organize these decentralized verification processes in the field of certificates. E.g. cacert.org, where you need a certain credit to sign and need a certain number of signers and documents verified. Maybe one could think about something like that for digital content. If I get the episode from 1959 as digital with the signature from a public library, I might trust it. If not, there might be a second one around, signed by another library, and if both are identical I might trust. Or one copy signed by two libraries. The question is if those libraries will spend the money on people verifying their digitized content, as this is not to be automated. And most of them suffer already from the efforts necessary to digitize content without "proof-reading"... Maybe the cheap, quick and dirty character of the web is part of its very nature, with proofed and verified content existing only on some small expensive islands... ;-) Lars. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] delineation and revision control
Yes, only some things would be versioned, or have different policies as Lalo suggests. Yes, child linking has to be preserved correctly. I think we can basically take an object's child list as part of its state. When you make a new version you might change those, or copy them whole from the original. In your example, the texture belongs to both I guess, but really, both objects have links/references to some objects, that it just happens to be the same one can be looked over for the most part I think. Reed On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote: > Well, Lars' suggestion of versioning only "interesting" parts and > your suggestion of horizons seem reasonable, but I don't think we > have the basis for this in VOS. A vobject usually cannot live as > isolated entity, but *requires* a number of relations to child > vobjects to make sense; thus any user-percievable "world object" is > actually a subgraph of the overall world graph. > > The problem is delineation: It is not clear which subgraphs represent > independent "world objects", or if there is even a distinctive > decomposition. For example, two objecs may share a texture - which > vobject does it "belong" to? If you change one vobject, do you > include the texture in the version? Where do you stop following > relational links? I don't recall if there is any prohibition in VOS > against cycles in the graph - I think there isn't - so matters become > even more complicated. > > The only separation I currently see in VOS is the relation between > the site vobject and its children, but even here it is not clear > which children represent aspects of the site itself, which are > scenery, and which are avatars. > > Any suggestions? > > Regards, > Karsten Otto (kao) > > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] delineation and revision control
Well, Lars' suggestion of versioning only "interesting" parts and your suggestion of horizons seem reasonable, but I don't think we have the basis for this in VOS. A vobject usually cannot live as isolated entity, but *requires* a number of relations to child vobjects to make sense; thus any user-percievable "world object" is actually a subgraph of the overall world graph. The problem is delineation: It is not clear which subgraphs represent independent "world objects", or if there is even a distinctive decomposition. For example, two objecs may share a texture - which vobject does it "belong" to? If you change one vobject, do you include the texture in the version? Where do you stop following relational links? I don't recall if there is any prohibition in VOS against cycles in the graph - I think there isn't - so matters become even more complicated. The only separation I currently see in VOS is the relation between the site vobject and its children, but even here it is not clear which children represent aspects of the site itself, which are scenery, and which are avatars. Any suggestions? Regards, Karsten Otto (kao) ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
On Wed, 09 May 2007 09:07:57 +0200, Karsten Otto wrote: > I don't quite understand what you need versioning for. The bulk of > changes you get in a shared word is avatar movement, which may wind up > to ~30 changes per second per avatar. Do you really want to keep a > record of all this? My understanding was that if you want to make a > movie, its your responsibility to do the recording (and filling your > hard disk), not that of the world/server. IMO, much of the "interesting" content may not actually be 3d objects, but rather, information (text, models, images, sound, the works) which you use the 3d objects to navigate trough and interact with. Anyway, in my mental model, the answer to that is horizons. For a document (akin to a wikipage), you may define an infinite horizon: all revisions will be kept. For most 3d content, the default horizon, which is to be defined -- a month, a week, 200 revisions? And for things like position of avatars, zero: no revision control at all. Alternatively, only record a revision when the object remains unchanged for some period of time... but this is hairy to implement and I'm not sure it would be worth it. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data"
> In effect, regardless of the wrapper, unless you have the original 1959 > first episode of Rocky and Bullwinkle, you probably can't answer those > trivia question correctly. There are some approaches to organize these decentralized verification processes in the field of certificates. E.g. cacert.org, where you need a certain credit to sign and need a certain number of signers and documents verified. Maybe one could think about something like that for digital content. If I get the episode from 1959 as digital with the signature from a public library, I might trust it. If not, there might be a second one around, signed by another library, and if both are identical I might trust. Or one copy signed by two libraries. The question is if those libraries will spend the money on people verifying their digitized content, as this is not to be automated. And most of them suffer already from the efforts necessary to digitize content without "proof-reading"... Maybe the cheap, quick and dirty character of the web is part of its very nature, with proofed and verified content existing only on some small expensive islands... ;-) Lars. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
> I don't quite understand what you need versioning for. The bulk of > changes you get in a shared word is avatar movement, which may wind > up to ~30 changes per second per avatar. Nice question, there must be a control on what is covered by versioning. It may be enough for some applications to have older versions only for the "world" without anything dynamic inside, so that versioning reflects only changes introduced by world developers. There may be cases where users (represented as avatars) change the world while interacting with it and those changes, but not information on the avatar itself should be put into versioning. Actually, if the world is thought of as a shared work environment, and folks are sketching and talking, than one could think of this process as something that could be implemented as versioning, and the interaction should be "recorded" for the time-span of the meeting. The interactive nature of worlds raises the question if we are talking about versioning or recording, and in this context the question of resolution (the 30 snapshots/second being a funny extreme). Sorry if this has all been discussed before, I am rather new on this list, but is sound very interesting to me and touching some key concepts necessary for future development of online content. CU Lars. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
I don't quite understand what you need versioning for. The bulk of changes you get in a shared word is avatar movement, which may wind up to ~30 changes per second per avatar. Do you really want to keep a record of all this? My understanding was that if you want to make a movie, its your responsibility to do the recording (and filling your hard disk), not that of the world/server. Regards, Karsten Otto (kao) Am 09.05.2007 um 00:13 schrieb Reed Hedges: >>> This means that if that version object is mutable, i.e. a not >>> read-only >>> property, we need to also have branches in the version history, >>> and any >>> reference to a past version of a vobjcet is really a reference to >>> "the >>> most recent version in the branch rooted on this object, which if >>> there >>> is only one version in the branch, is the same as the root >>> object" [if >>> that makes any sense]. >> >> I don't understand. > > The example I was thinking of is this: > > Property P has versions P.1, P.2, P.3. If you have a normal reference > to P, you get P.3, though you know it just as P. If you write to > P, it > creates a new version, P.4, but P (being the "current version") is > transparently changed to P.4. But if you have a reference to > P.2, and you write to it, resulting in a new version P.2.2, it appears > to you that the write didn't work, since you're still looking at P.2. > So P.2 needs to be an alias for "most recent version of P.2" in the > same > way that P was. P.3 is then also an alias for "most recent version of > P.3", but P.3 doesn't have any derivative versions, so it's just P. > 3 (or > call it P.3.0 or something). > > Reed > > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
