Re: [vos-d] s5 design overview
Ken Taylor wrote: Peter Amstutz wrote: 1. Memory footprint The current s4 design has a lot of per-vobject overhead, leading to a significant memory footprint. The development version improves on this a bit, but the honest truth is that the implementation was not written with memory efficiency in mind. The s5 design will attempt to address in various ways, including attempting to directly minimize the byte count of crucial classes and data structures, and by using the flyweight pattern to collapse identical classes into a single shared instance. In particular, symbols (method names, message fields, types, etc) will be stored in a single global symbol table. This will ensure that such strings (which are expected to be used a lot in the system) are not duplicated, and has the convient effect of also making string comparison a constant-time pointer comparison instead of a linear time compare. This seems like a very good optimization, given how string-heavy the system is. Could string tables also be used to compress COD files more? How about network optimization by having two sites share a string table (or have a static standard string table of commonly used strings in the core protocol?). Also ... are properties stored as strings at the moment or as native bytes (I actually don't know this)? If they're stored as strings, compressing them to native data structures would probably be a big win too (same thing goes for properties with storing them in COD and sending them over the network). [I also had another idea related to network optimization -- which is unrelated to memory footprint. The idea is particularly for large worlds with lots of objects to listen to: instead of listening update messages sending the whole message string and object identification, etc, have an optimized listen protocol, where a chosen-at-runtime tag is used to identify a certain kind of update message coming from a specific object, and that's all you need to have in the network traffic (other than the actual updated values, of course). This could even be done transparently at the network interface level] Another method for making the most out of the memory will be the ability to load vobjects from persistant storage on demand, and swap out rarely used vobjects. This will allow a site to contain many more vobjects than would otherwise fit in RAM. This Could this also be extended to support persistant transparent caching of remote sites that have been visited? Perhaps paired with a new method to query certain information about vobjects, such as is-cacheable and last-updated/version? To reduce the footprint of vobjects themselves, I am introduce a concept called embedded children. These are objects that appear in protocol terms to be independently addressable vobjects that can send and receive messages, but are actually stored as a field of another vobject. This emerged from the observation that while it was extremely powerful from a design pattern standpoint for properties to be first-class vobjects, in s4 this often led to situations where it hundreds of bytes of overhead to store even a single four byte integer (for example). As an embedded child, the child vobject is simply a normal data field in the parent class, and it falls upon the parent sends and receives messages on behalf of the child. Sounds reasonable... What reasons (other than asthetics/symmetry) are there for properties to be first-class? Will a property object ever have children? Will one ever be at site root with no other parent? Will one ever be a meta-object other than property? I guess you could have two parents sharing the same property if it's a big one ... Heh, well actually we tried that :) In s2 properties were indelible components of their parent objects. But it made everything more complicated and made the properties themselves much less useful. Being able to share properties is a critical feature of VOS that has emerged. And all the usefulness that comes from metaobjects/vobjects too-- Pete mentioned FileProperty and ExtrapolatedProperty (which no longer exist), but the new vostoolbox library I've been working on recently has several property subclasses; since they're metabobjects you can instantiate them remotely (e.g. in mesh, create foo property:property.foo With s5's new embedded children, you will still be able to optionally override an embedded child with a full Vobject. Yes. I've run into this ls at site root problem and it's a bit annoying :) And orphaned vobjects just seem like a lose. Related to this, I added a new setting and command to mesh, cache. The setting does an initial request for all objects when you enter a new object to cache them. This doesn't actually solve the problem (since you still have to wait for the initial cache) but it makes the actual ls command operate at a reasonable speed. Set settings in mesh with the set command (and you can
[vos-d] Flux Worlds Server Announcement
---BeginMessage--- Folks, We've been up to something over here - thought I would tell you about it before you heard it on the street. Media Machines has been developing a multi-user server based on a new protocol that we intend to put out into the open. We have dubbed it Simple Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is to work with Web3D and potentially other organizations to standardize SWMP. We will also supply a basic open source implementation. Our overriding goal-- one that we are pursuing with total passion and vigor-- is to create an open infrastructure for the Metaverse. We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds is currently in alpha test. While the product is still several weeks away from beta test, we announced it yesterday with the goal of attracting early signups for the beta. We are also integrating a prototype of the new X3D networking nodes being developing by the Networking Working Group, right into Flux Player. The results look promising. Anyway, here is the announcement. We would love to have you be part of the beta when it's ready! http://www.mediamachines.com/press/pressrelease-03292007.php Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. Yours virtually, Tony - Tony Parisi 415-902-8002 President/CEO [EMAIL PROTECTED] Media Machines, Inc.www.mediamachines.com Add 3D content to your web page with the Flux Player. Go to www.mediamachines.com to upload and share your 3D content. - - for list subscription/unsubscription, go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html ---End Message--- ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Flux Worlds Server Announcement
Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. I agree with this, and I'm glad that more and more people are realizing it. However, though it's necessary, it's not sufficient to create the metaverse. Some other requirements I would use to evaluate any metaverse system: - Not only can anyone run a server, but they can easily interlink and users can freely traverse the spaces between different servers, with the potential for seamlessly connecting virtual spaces (eg, with portals). - The protocol is future-proof and can keep up with developments in technology and new ideas for interaction while maintaining backwards compatibility and a reasonable experience for those with hardware or bandwidth that can't support the latest-and-greatest - The protocol should support use creation and ownership of content, including a flexible scripting system, and the ability to transfer user-created content between servers. It should support collaborative editing and interaction with content. - The protocol is highly extensible through 3rd-party plugins and not locked-in to whatever the committee decided at standardization time was, for example, the best parameterized-avatar system/voice-chat system/streaming-video protocol/physics system/what-have-you. However, at the same time, there should be a robust baseline spec that allows all users to have a decent experience even with no plugins added. I definitely see VOS as having the potential to meet all these requirements and beyond. I can't really tell from the press release how far they are planning to go with flux worlds. My guess is it's going to be yet-another-shared-space-server, this time based on X3D and easily integrated with web pages. So it'll probably be really neat, but not the metaverse yet ;) -Ken - Original Message - From: Tony Parisi [EMAIL PROTECTED] To: 'x3d-public list' [EMAIL PROTECTED]; 'www-vrml' [EMAIL PROTECTED] Sent: Friday, March 30, 2007 2:08 PM Subject: [www-vrml] Flux Worlds Server Announcement Folks, We've been up to something over here - thought I would tell you about it before you heard it on the street. Media Machines has been developing a multi-user server based on a new protocol that we intend to put out into the open. We have dubbed it Simple Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is to work with Web3D and potentially other organizations to standardize SWMP. We will also supply a basic open source implementation. Our overriding goal-- one that we are pursuing with total passion and vigor-- is to create an open infrastructure for the Metaverse. We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds is currently in alpha test. While the product is still several weeks away from beta test, we announced it yesterday with the goal of attracting early signups for the beta. We are also integrating a prototype of the new X3D networking nodes being developing by the Networking Working Group, right into Flux Player. The results look promising. Anyway, here is the announcement. We would love to have you be part of the beta when it's ready! http://www.mediamachines.com/press/pressrelease-03292007.php Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. Yours virtually, Tony - Tony Parisi 415-902-8002 President/CEO [EMAIL PROTECTED] Media Machines, Inc.www.mediamachines.com Add 3D content to your web page with the Flux Player. Go to www.mediamachines.com to upload and share your 3D content. - ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Flux Worlds Server Announcement
We learned the really hard way in the early years of VRML to take it slow when trying to create something intended to scale out the Internet. I won't quarrel with your requirements but I also am very leary of anything that reeks of Snowcrash-like thinking or visions. We got burned because that sort of thinking leads to expectations that are not just impossible in the short term, they aren't achievable. VRML still gets hammered in books, blogs and other articles for overreaching and not hitting those marks despite the fact that as a standard, ten years later, the content still works with current tools and a lot of current content sill works with old tools. That is what a standard has to achieve. Don't overdrive your headlights. It's a deadly mistake. So I'm not criticizing, but take it to the bank that Parisi knows better than anyone what the cost of overreaching is. Your 'metaverse' is worth having, but he is good ways down the path of making his work now and he has been at the forefront of getting such standards built for over a decade now. He isn't 'now' realizing; he paid the price in blood before most of the rest of the current crowd was even trying. len -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Taylor Sent: Friday, March 30, 2007 9:10 PM To: VOS Discussion Subject: Re: [vos-d] Flux Worlds Server Announcement Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. I agree with this, and I'm glad that more and more people are realizing it. However, though it's necessary, it's not sufficient to create the metaverse. Some other requirements I would use to evaluate any metaverse system: - Not only can anyone run a server, but they can easily interlink and users can freely traverse the spaces between different servers, with the potential for seamlessly connecting virtual spaces (eg, with portals). - The protocol is future-proof and can keep up with developments in technology and new ideas for interaction while maintaining backwards compatibility and a reasonable experience for those with hardware or bandwidth that can't support the latest-and-greatest - The protocol should support use creation and ownership of content, including a flexible scripting system, and the ability to transfer user-created content between servers. It should support collaborative editing and interaction with content. - The protocol is highly extensible through 3rd-party plugins and not locked-in to whatever the committee decided at standardization time was, for example, the best parameterized-avatar system/voice-chat system/streaming-video protocol/physics system/what-have-you. However, at the same time, there should be a robust baseline spec that allows all users to have a decent experience even with no plugins added. I definitely see VOS as having the potential to meet all these requirements and beyond. I can't really tell from the press release how far they are planning to go with flux worlds. My guess is it's going to be yet-another-shared-space-server, this time based on X3D and easily integrated with web pages. So it'll probably be really neat, but not the metaverse yet ;) -Ken - Original Message - From: Tony Parisi [EMAIL PROTECTED] To: 'x3d-public list' [EMAIL PROTECTED]; 'www-vrml' [EMAIL PROTECTED] Sent: Friday, March 30, 2007 2:08 PM Subject: [www-vrml] Flux Worlds Server Announcement Folks, We've been up to something over here - thought I would tell you about it before you heard it on the street. Media Machines has been developing a multi-user server based on a new protocol that we intend to put out into the open. We have dubbed it Simple Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is to work with Web3D and potentially other organizations to standardize SWMP. We will also supply a basic open source implementation. Our overriding goal-- one that we are pursuing with total passion and vigor-- is to create an open infrastructure for the Metaverse. We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds is currently in alpha test. While the product is still several weeks away from beta test, we announced it yesterday with the goal of attracting early signups for the beta. We are also integrating a prototype of the new X3D networking nodes being developing by the Networking Working Group, right into Flux Player. The results look promising. Anyway, here is the announcement. We would love to have you be part of the beta when it's ready! http://www.mediamachines.com/press/pressrelease-03292007.php Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. Yours virtually, Tony - Tony Parisi 415-902-8002 President/CEO [EMAIL PROTECTED] Media
Re: [vos-d] Flux Worlds Server Announcement
Some good point Ken, and I think some should find their way into the NWWG requirements. I would add that the protocol should support the efficient implementation of a heartbeat. This sounds pretty specific but I think the abitily of a system to know that the server and clients are responding and how long it is taking them to respond is important. Single byte or word UDP payloads wrapped in a v small packet should suffice for this. I use a use case based on eve-online: think of a player who has invested hundreds of millions of isk (in-game currency) on a battleship and 1.5 years training/playing to get there. In a battle with NPC pirates the server lags badly. Madly typing at the keyboard produces no response and he cannot get his active armor or weapons online. Meanwhile the server the NPC pirates are destroying the ship with no status update at the client. The player gets s couple of updates: one showing his ship 3/4 destroyed - he tries warping out but the server does not respond in time. His next update is pieces of ex- battleship. Now in this scenario, if the heartbeat system is not in place then there no indication the ship was lost through player incompetence or because of a server side issue. Sure, the vendor may have stats on server load that would back a petition from the player for his ship back, but I think a heartbeat system would be valuable in this case. cheers, chris On 31/03/07, Ken Taylor [EMAIL PROTECTED] wrote: Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. I agree with this, and I'm glad that more and more people are realizing it. However, though it's necessary, it's not sufficient to create the metaverse. Some other requirements I would use to evaluate any metaverse system: - Not only can anyone run a server, but they can easily interlink and users can freely traverse the spaces between different servers, with the potential for seamlessly connecting virtual spaces (eg, with portals). - The protocol is future-proof and can keep up with developments in technology and new ideas for interaction while maintaining backwards compatibility and a reasonable experience for those with hardware or bandwidth that can't support the latest-and-greatest - The protocol should support use creation and ownership of content, including a flexible scripting system, and the ability to transfer user-created content between servers. It should support collaborative editing and interaction with content. - The protocol is highly extensible through 3rd-party plugins and not locked-in to whatever the committee decided at standardization time was, for example, the best parameterized-avatar system/voice-chat system/streaming-video protocol/physics system/what-have-you. However, at the same time, there should be a robust baseline spec that allows all users to have a decent experience even with no plugins added. I definitely see VOS as having the potential to meet all these requirements and beyond. I can't really tell from the press release how far they are planning to go with flux worlds. My guess is it's going to be yet-another-shared-space-server, this time based on X3D and easily integrated with web pages. So it'll probably be really neat, but not the metaverse yet ;) -Ken - Original Message - From: Tony Parisi [EMAIL PROTECTED] To: 'x3d-public list' [EMAIL PROTECTED]; 'www-vrml' [EMAIL PROTECTED] Sent: Friday, March 30, 2007 2:08 PM Subject: [www-vrml] Flux Worlds Server Announcement Folks, We've been up to something over here - thought I would tell you about it before you heard it on the street. Media Machines has been developing a multi-user server based on a new protocol that we intend to put out into the open. We have dubbed it Simple Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is to work with Web3D and potentially other organizations to standardize SWMP. We will also supply a basic open source implementation. Our overriding goal-- one that we are pursuing with total passion and vigor-- is to create an open infrastructure for the Metaverse. We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds is currently in alpha test. While the product is still several weeks away from beta test, we announced it yesterday with the goal of attracting early signups for the beta. We are also integrating a prototype of the new X3D networking nodes being developing by the Networking Working Group, right into Flux Player. The results look promising. Anyway, here is the announcement. We would love to have you be part of the beta when it's ready! http://www.mediamachines.com/press/pressrelease-03292007.php Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. Yours virtually, Tony - Tony Parisi 415-902-8002 President/CEO
Re: [vos-d] Flux Worlds Server Announcement
Because when you don't hit the mark, it causes people to throw the baby out with the bathwater. Visions are ok, but lots of publicity and preannouncements without the goods takes on the rep of being snake-oil. It is a very bad strategy to get into a market with the aim of eliminating all competitors. It screws the customers over. Netscape made that mistake and they had their collective rears handed to them. To me, metaverse is just another word. It has no ownership and only as much meaning as there is running code to support it. It's like saying 'Heaven' and then setting up the dogma without the pragma. So no offense, but don't get possessive with a term. Offering up suggestions is cool. It is cooler to offer them with running code. He isn't exactly playing it safe. He has code, he spent the company money to get it ready for open source, and he has the access to the standards editors. Is it more of the same? We've had shared spaces but no standard for hooking those up without buying Blaxxun Community server or any of the various other products. All we've had is client standards. What Tony is talking about is a protocol that can be implemented anywhere, and possibly a reduction in costs for authors to have worlds that is ten percent of what it costs to host at LL. That is significant. Now don't get me wrong, I am not quarreling with the VOS vision or the work. I'm saying if he manages to get this done, it puts something on the street a lot of people need, so stepping back and saying that's not a true Metaverse is sour grapes. No one really knows what a metaverse is. You know what you want it to be and that is cool, but not authoritative or a reason to say he doesn't have one. We got in trouble by promising a science fantasy world that couldn't be built then if ever, and it turned people off to 3D on the web for ten years. If he gets shared spaces out there for ten percent of the cost of SL and does it with content standards that enable the content to move around among worlds without being hostage to POTS server farm market, that is an AMAZING and very revolutionary accomplishment. Give him cred, then get back to your vision and show the next new thing when it is ready to show. It's bad karma to climb up the backs of other swimmers trying to stay afloat in the same ocean. len -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Taylor Sent: Friday, March 30, 2007 9:59 PM To: VOS Discussion Subject: Re: [vos-d] Flux Worlds Server Announcement I think that a basic open-standard shared-space server based on X3D is an obvious and safe step -- Flux Worlds will probably be very successful at what it does. But in my view, it doesn't bring us any closer to the metaverse and I hate when people through that word around (ever since the Lindens started doing so). To me it really is just more of the same -- we've had shared space servers around almost as long as VRML itself, and we're not that much closer to a true interconnected 3d universe on the internet. Someone has to stop playing it safe for anything revolutionary to occur. But what's wrong with snowcrash-like thinking or visions anyway? ;) -Ken - Original Message - From: Len Bullard [EMAIL PROTECTED] To: 'VOS Discussion' vos-d@interreality.org Sent: Friday, March 30, 2007 7:47 PM Subject: Re: [vos-d] Flux Worlds Server Announcement We learned the really hard way in the early years of VRML to take it slow when trying to create something intended to scale out the Internet. I won't quarrel with your requirements but I also am very leary of anything that reeks of Snowcrash-like thinking or visions. We got burned because that sort of thinking leads to expectations that are not just impossible in the short term, they aren't achievable. VRML still gets hammered in books, blogs and other articles for overreaching and not hitting those marks despite the fact that as a standard, ten years later, the content still works with current tools and a lot of current content sill works with old tools. That is what a standard has to achieve. Don't overdrive your headlights. It's a deadly mistake. So I'm not criticizing, but take it to the bank that Parisi knows better than anyone what the cost of overreaching is. Your 'metaverse' is worth having, but he is good ways down the path of making his work now and he has been at the forefront of getting such standards built for over a decade now. He isn't 'now' realizing; he paid the price in blood before most of the rest of the current crowd was even trying. len -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Taylor Sent: Friday, March 30, 2007 9:10 PM To: VOS Discussion Subject: Re: [vos-d] Flux Worlds Server Announcement Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. I agree with this, and I'm glad that more and more
Re: [vos-d] http://interreality.org/wiki/YiMeiyou
On Thu, 29 Mar 2007 17:32:17 -0700, HEBLACK, J wrote: http://interreality.org/wiki/YiMeiyou The faq at the above page is missing. All the links are missing; I let my laranja.org domain expire, accidentally :-( I'll be setting up new addresses for all that stuff shortly. 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. - 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] s5 design overview
On Thu, 29 Mar 2007 07:29:35 -0700, Ken Taylor wrote: Sounds reasonable... What reasons (other than asthetics/symmetry) are there for properties to be first-class? Will a property object ever have children? Two use cases we encountered in the past for putting children in a property: - Translations. Depending on the data, the translation can be a further property inside the property, or it can be a sibling, with each language version having a property containing the language code. - And misc:metadata, of course; you can surely imagine lots of situations where you'd want to store a date, author information, etc for a property, right? 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. - 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
