Kripken - just what do you mean by "for what it does"? Ryan - the animated avatars, distributed assets, portable inventory, and deployment tools you mention would fit nicely into the MXP model, but would not be built directly into the "server". And I believe the architecture enabled by MXP gives an advantage here by not expecting everything to be built into a monolithic server.
HTTP is not used merely for "transferring web documents", obviously. It is used for much more than it was designed for, and indeed many things it is not good for. But as a "one protocol" it has enabled a fantastic culture of cooperation among server and client developers - one group's browser or middleware works with another group's server or service. You don't have the architectural silos that epitomize virtual world platforms. Arkowitz On Oct 22, 11:18 am, Ryan McDougall <[email protected]> wrote: > Is there an example you can point me to that demonstrates an MXP > implementation that delivers a complete VW experience; from fully > animated avatars, to distributed assets, portable inventory, > deployment tools, etc? > > My point is given the point in time of our project, we have to deliver > the best application platform in order to survive. The goal of having > an "HTTP" is admirable, but people don't buy the protocol, they buy > the application or service -- youtube or gmail. > > Moreover, you cannot compare the web and VW so directly. Sharing > documents on the internet is an order of magnitude simpler problem. > The reason we have so many VW protocols is that everyone thinks they > can do something better, and there is no obvious right answer yet. > This is a huge reason why Naali is intended to be a multi-protocol > viewer: betting the house on one implementation is not wise. > > Never the less, the answer remains the same: we don't have resources > to implement every conceivable protocol; we will get to it when we are > able. If anyone would like to have it sooner than that, please stop by > our IRC, and we can help you get it implemented in Naali. > > If anyone really things it makes better sense to implement MXP than LL > protocols, there's a standing invitation to make that case. > > Cheers, > > > > On Thu, Oct 22, 2009 at 3:49 PM, arkowitz <[email protected]> wrote: > > > The goal of supporting "all protocols" is admirable, but impossible. > > The protocol used for virtual world communication will always > > explicitly or implicitly affect the architecture of the system as a > > whole. > > > MXP was created to allow virtual worlds to be architected properly. > > One example of this is the way avatars are treated just like other > > objects owned by participants and possessing awareness bounds. This > > is an important principle and should affect the architecture of the > > server. > > > Ultimately there should be one protocol. Think about it... how many > > alternatives to HTTP are there? > > > Arkowitz > > > On Oct 19, 6:33 am, Ryan McDougall <[email protected]> wrote: > >> The ideal situation is that realXtend Naali supports all virtual world > >> protocols, so yes one day we'd like to support MXP. Unfortunately, > >> given how short of resources we are compared to the scope of the > >> problem, we are limited by not having anyone come forward to implement > >> MXP support within Naali. > > >> If you'd like to contribute to MXP support for Naali, please let me > >> know. I've already asked Tommi Laukkanen to present a proposal about > >> MXP, but understandably, he is also a very busy man. > > >> Cheers, > > >> On Mon, Oct 19, 2009 at 7:24 AM, mengzhehai china > > >> <[email protected]> wrote: > > >> > Realxtend will use the MXP protocol in the future? > >> > Opensim is using the MXP now. > >> > Whether to build a service project using C++ or python If realxtend > >> > use the MXP? > >> > Many people can work for it ,the server will run on Linux/Unix better > >> > than now . > > >> >http://www.bubblecloud.org/ --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/realxtend http://www.realxtend.org -~----------~----~----~----~------~----~------~--~---
