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 _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev