[Opensim-dev] Client-side API/scripting Re: LookingGlass Viewer progress

[Toni Alatalo]

Dzonatas Sol kirjoitti:
> Mister Blue wrote:
>   
>> Several people are playing with protocols and I am intrigued by the 
>> possibilities of a better protocol.
>>     

That is the case with realXtend development now too. The new Naali 
viewer has the basics of the old things implemented now, against the 
pre-existed server implementations using the sl protocol. But one of the 
reasons for writing a new viewer was to be able to switch to another 
protocol, or perhaps even support multiple protocols for different 
services like has been discussed recently.

We've having a short (1-2) weeks research period in early January, 
besides finalizing things for the Naali 0.1 release in late January, and 
one of the things will be looking at more closely now is protocols. MXP 
has been in the talks and something like that might be what we need, 
let's see.

Basically the idea is to have something good for transferring the 
default movement updates etc. efficiently, and then a way to describe 
application specific custom messages that would be efficiently 
transmitted as well - not kind of second class citizens like the generic 
messages in the sl protocol. Something like Google protocol buffers, 
perhaps.

> Let's say there are two main routes for protocols in regards to this 
> area. Between the grid/server and the viewer/client is more of the 
> easiest one to point out. We can call this route as being in the Agent

Fair enough, so the above was about the former.

> could say it is within the User Domain. The User Domain is where all the 
> client-scripts and interfaces communicate.
> If we can somehow standardize the REST/HTTP based APIs, then that would 
> be a key element to many developers that make human-computer interfaces 
> and want to make them more immersive. This also applies for those that 
> just want their developer tools to 'just-work' easier with the Agent 
> Domain without the the need to write an entire new viewer. (i.e. a 
> blender plug-in that can easily import/export a "live" version of an 
> object before it is uploaded to the grid -- or, a movement control to 
> help machinima be easier and be supported separately from the viewer).
>   

That has been one of the goals in the Naali development, actually the 
one I've been personally responsible for. One of the motivations 
actually being Blender integration, but mostly to enable making things 
to the viewer itself. Also on the c++ level Naali is a module framework, 
with the idea is that anyone can write the modules they want - indeed to 
not have to write a viewer, but the own modules, inspired by the idea of 
Opensim itself. But what I've been working on is the same for 
interpreted langs, so far Python and Javascript.

Currently the editing UI in Naali, also in the 0.0.2 developer preview 
release we made in October and enhanced in trunk, is a plugin that could 
well be written by a 3rd party and the core doesn't know anything about 
it - just provides a powerful enough API that you can do object 
placement in 3d using the mouse, draw local graphics to hilite the 
selected scene object, and make gui widgets using qt etc. It shows in 
the first screenshot in 
http://wiki.realxtend.org/index.php/Getting_Started_with_Naali#What_is_Naali.3F 
- the panel called World Edit, and it's also responsible for showing the 
movement arrows that are drawn with the Ogre head. The source for this 
py plugin is at 
http://code.google.com/p/realxtend-naali/source/browse/trunk/bin/pymodules/editgui/editgui.py 
- the idea is to support similar stuff for Javascript too, for more info 
see http://wiki.realxtend.org/index.php/Interpreted_Languages_Working_Group

The API for manipulating objects, tracking the mouse etc. was actually 
developed for other reasons starting in spring (we wan't to make custom 
UIs for our arcade games at Playsign), but coincidentally it fitted that 
basic UI tool too so has been used to write that. The idea now has been 
to use the editing UI as a proof and driver for the API, trusting that 
it can then used by others for many kinds of other things too (and 
indeed to customize / enhance the editing itself more easily).

We started the work by manually exposing c++ things to Py while 
evaluating the automated tools for it, and later when the project 
adopted Qt for UI, we've started using the object metadata system of Qt 
for scripting support as well. The slots (methods) and properties of 
QObjects show automagically to Python via PythonQt, and to Javascript 
via QtScript. Also the normal Py & Qt things are available, so you can 
things like http requests and show qt webviews etc. (the source of the 
w.i.p mediaurl handler featuring a WebView to render HTML to show as 
textures in Naali  is 
http://code.google.com/p/realxtend-naali/source/browse/trunk/bin/pymodules/mediaurlhandler/mediaurlhandler.py)

Another experiment I did in July was to have a Py written http server 
running inside Naali: 
http://wiki.realxtend.org/index.php/Naali_webserver_plugin .. the source 
in current place 
http://code.google.com/p/realxtend-naali/source/browse/trunk/bin/pymodules/webserver/webcontroller.py

This I think could be used to support your idea, a HTTP/REST api for 
UIs? There is a very easily extensible http handler that runs with the 
viewer code already, and it has all of the API we have at hand and we 
need that API to be powerful in any case. We're now in the progress of 
converting things to QObjects so more would be available -- the first 
thing that have been experimenting with now is the Prim data, including 
the geometry parameters, that all show to py (and would for js) now but 
we have to complete the backend work to have them actually do the 
modelling locally and sync over the net too.

> Here is the main project site for MonoVida Communicator, which also uses 
> REST/XML to run in separate process and communicate with the viewer:
> http://jira.dzonux.net:8080/browse/MVC
> The Chat/IM/Contacts panels are separated/detached:
> http://mono.dzonux.net/file/MonoVida-20090701a.png
>   

This seems very interesting, I've been curious if these kinds of plugins 
on top of client side APIs will appear and whether we can have them 
interoperable in different viewer projects, and this seems like 
something that could work. I was reading the MonoVida notecard thing in 
the sources, am not sure what part was which - what would be a good doc 
or an example covering a set of REST calls that we should have 
implemented in Naali for your plugins to work?

Our communications module uses QObjects quite a lot, was written in 
autumn when we knew that will use Qt things for py&js support, so should 
be easy enough to expose in the py written url handler I have. Of course 
if needed we or anyone can write a c++ rest handler module to Naali as 
well, but I don't know why that would be necessary (just more work?).
 
> The patch as applied to Imprudence:
> http://github.com/ArminW/imprudence/tree/snow375
>   

I guess the other things you mentioned are safe to read for Opensim 
developers, but that one is with Linden viewer source so studying that 
would validate the contributors agreement here? So skipped this one so 
far :) .. a spec of the http requests and/or the existing plugins that 
are written against are the things to read when implementing this to 
other viewers I think, will take a look at the comms stuff now.

Thanks for the info!

> Dzonatas
>   

~Toni