David,
With this latest refactoring came the new Simulation service,
represented by ISimulationService. Please take a look at it. The data
structures that it currently takes for creating and updating agents
are still incomplete (one of them needs more data for foreign users),
but I think you'll get the idea very quickly. We may be able to come
up with the basic common data, and then have more specialized data
structures for each agent transfer protocol.
I took a look at the OGP module the other day, and it really looked to
me like it can be written as an alternative handler that receives/
sends the data from/to the wire using the specific protocol that you
guys have been cooking, but that calls the existing simulation service
exactly like the existing handler. The existing handler is in
OpenSim.Server.Handlers.Simulation.
There were several important details that you obviously need to make
decisions upon, like -- do you really want to create a persistent
account for foreign users? etc. As I was about to do the rewrite of
that module for the new services, it was obvious that I couldn't make
that call, or I would be designing OGP myself :)
As I was hoping, I think this will be an excellent vehicle to discuss
similarities and differences between OGP and HG and any other agent
transfer protocols out there.
Crista / Diva
On Jan 7, 2010, at 1:29 PM, David W Levine wrote:
There's a more recent copy on the github repository linked to out of
gridforge. (gridforge still being SVN is... a wee challange) The
tree there is a light fork off
of September. There are a couple of changes which permit inventory
to run from caps hosted by the Agent Service in that tree, as well
as some code to manage
reflecting region inventory interactions to the Agent Service.
git://github.com/zekizeki/agentservice.git That should be current.
I've been giving the right way to sync up a bit of thought. I
suspect that the OGP module really wants to be built at a different
layer in the post re-factor world, probably
as a service, using the connectors to talk to the rest of the system
like any other well behaved component. The basic task of the OGP
code is to parse the request from
a remote Agent Service, decide whether to accept it or not, and
then, setup the region to welcome the client. Currently the OGP code
stuff things into the region with a bit
of a sledghammer. I'd think doing it properly, with connectors would
be much nicer for everyone, and isolate the code properly. I suspect
the biggest tricky bit is whether
the right bits are exposed to have the region ready to talk to the
client with the right agentID, secure Circuit ID, and a properly
setup user agent to match. I'll start looking
at that in the current connector code.
Overall, the connector approach, and getting as many of the services
decoupled is clearly the way to go, especially, if we want to allow
everyone to explore a range of
messaging, inventory and asset serving models over the next chunk of
grid evolution. I'm hopeful we can start getting some really useful
evolution to happen pairwise in the
clients and the services this year, which should make everyone's
life more flexible.
- David
[email protected] wrote on 01/06/2010 01:14:32 PM:
> [image removed]
>
> Re: [Opensim-dev] OGP module and the grand re-factor...
>
> diva
>
> to:
>
> opensim-dev
>
> 01/06/2010 01:14 PM
>
> Sent by:
>
> [email protected]
>
> Please respond to diva, opensim-dev
>
> Hi David,
>
> First question is: what's the most updated version of OGP? Is it
what's
> currently in the core distro, or do you have something more recent
> somewhere else?
>
> Diva / Crista
>
> David W Levine wrote:
> >
> > I gather the current grand refactoring is washing up on the
shores of
> > the OGP module (which is hardly surprising) So, I'll raise my
hand and
> > say "I'll make sure it gets sorted out" I gather Melanie and
DIva are
> > looking
> > for that hand raise, so here it is. Since I'm also about to look
at
> > adding in X.509 based counterpart validation to the code this
month,
> > I'll be in there anyway. So... Lets sort out what's needed to
make this
> > as painless as
> > possible for everyone.
> >
> >
> >
> > - David / Zha
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [email protected]
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
