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).
> 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
> - kripken
a bit to Arkowitz too:
>
> Many fine efforts will continue to go nowhere as long as devs are
> forging ahead without a proper and deep discussion of architecture.
> Issues and principles such as we are getting to in this conversation,
> in a roundabout way, should be discussed prior to running down the
> primrose path with code.
>
Basically the situation with Realxtend is that the 'next generation'
roadmap started with the idea that we needed a new viewer codebase as
some kind of a plugin system, an extensible modular framework. But also
to soon quite straightforwardly implement the existing / legacy protocol
for which there already was the working servers, ready made demo worlds
etc., and features those need to the viewer.
That has now been largely done. Should become actually usable by early
next year or so, a working replacement for some things at least.
But the whole idea is to go beyond, start getting the new features --
the ones for which we needed the new architecture. And this 'html +
javascript' analogy related idea of having a generic platform that can
run many apps, with different UIs and behaviours etc., is one we've been
pursuing. It just now is in the 'next year when basics are done enough'
department. But we do keep research periods and parallel research tasks
etc going on, might be a good time to look at e.g. Syntensity things
(also reading the sirikata protocol spec is still waiting in my todo)
after a few weeks or so when 0.0.2 is out the door.
One thing Jonne and Ryan were doing a couple of weeks ago was this
protocol module refactor, separating login stuff related to auth to a
WorldSession and then the realtime 3d coords etc stuff to WorldStream,
as a step towards adding(/switching) protocols (to mxp or sirikata or
whatever syntensity uses or something). So we are not quite there yet,
but aiming at and working towards at some point.
> Arkowitz
>
~Toni
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/realxtend
http://www.realxtend.org
-~----------~----~----~----~------~----~------~--~---
