On Wed, Oct 28, 2009 at 11:26 PM, Toni Alatalo <[email protected]> wrote:
>
> Kripken kirjoitti:
> > The bottom line in my definitions is this: In a 'continuous'
> > architecture, all the regions behave in one way - be it SL, or Quake,
> > or something else. That is still quite flexible, just as you said
> > (users can change their avatars, etc.). But in a 'non-continuous'
> > architecture, one region can behave like SL, another like Quake, and
> > another otherwise, while at the same time all are accessible with a
> > single client. That was a requirement for us during our planning
> > stage, and it is what led to our current architecture and implementation.
>
> And based on what has been said here, seems to me MXP was made for that
> too. The talk about it just relaying messages between participants:
> isn't it exactly so that applications, worlds, whatevers, can have their
> own code and use their own packet types there? And MXP just basically
> says 'you can use google protocol buffers for that' ? Which itself has
> seemed good to us, for making e.g. games, which typically need custom
> packets (like 'bomb exploded', and sometimes e.g. spherical movement code).
>
>
Yes, MXP can be used for it, and as I said, I would be happy to use MXP
(if/when it supports the necessary features). But it would be just a subset
of MXP, without e.g. the position/movement updates and so forth. And my
main point is that a *fixed* protocol using Google Protocol Buffers etc. on
top of MXP, isn't enough; the protocol needs to be able to change in each
area you connect to. And as I said, once you are talking about different
protocols in each area, the fixed part of the protocol (MXP or something
else) becomes the less interesting matter.
> > To compare to the web: MXP is a parallel for HTTP, while the
> > Syntensity API is a parallel for JavaScript (the core language + the
> > standard web browser stuff). To continue the analogy, having just MXP
> > is like a web browser without JavaScript - it can only show HTML ('one
> > type' of virtual world, in the analogy). That is why I said that the
> > language + API was more interesting to me: The
>
> I've been for quite a while now trying to stay on track of what we could
> perhaps do in client APIs, with regards to perhaps standardization or
> some kind of interoperability.
>
> And in the development of the Naali API, the idea is exactly that it
> should allow the kind of things that DOM enables for html+javascript,
> but for virtual worlds - whatever that means. For some apps it may be
> that the equivalent of the DOM document is the vw scene, but largely I
> think also basic UI things like raycasting and perhaps getting touch
> events on the client side etc., like mouse stuff etc is of course
> important in browser apps like google maps.
>
> It is interesting that even the Linden viewer has something a little bit
> in this direction .. in letting scripts override arrowkeys (e.g. driving
> game retro arcade coin machines), kind of client api stuff,
>
> but of course things like different space types, coordinate systems or
> something are a bit different question. Like said I've been thinking
> that a scene object is easily useful for many things, the first useful
> thing in Naali API was that ob&rot&scale are exposed for all entities.
> It's now used in the editing gui plugin, but the hope in developing that
> tool and the api for it has been that it would also give tools for
> writing own custom behaviours in games or other apps. We have some games
> of our own from where have drawn requirements, those are in the wiki if
> someone is curious (when it comes back on-line..)
>
> > language + API is what allows a 'non-continuous' architecture to run
> > both SL-like and Quake-like worlds with the same client, which is what
> > I am interested in.
>
> So what is required from that API..? :p
>
Of course, the API/DOM must allow stuff like you mentioned above, including
input handling, entity/object control, visual effects, sound, etc. etc. That
stuff is an area where I do not think much innovation is needed, it is
fairly straightforward.
My argument here has been that such an API/DOM needs to also allow each
region to have its own custom network protocol. I don't see any other way
that would allow a single client to connect to different kinds of worlds,
SL/Quake/ etc. So that is what Syntensity uses, and I don't think we have
found any fundamental problems with the approach so far.
Btw, to repeat myself from the past, I would be very happy to work with
realXtend on this. The less duplicated effort the better.
- kripken
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/realxtend
http://www.realxtend.org
-~----------~----~----~----~------~----~------~--~---
