There's an interesting thought lurking there. Some of these choices
are going to be made by the grid builders,
not the protocol builders. I think, in a *lot* of cases, Meadhbh is
right. The visiting avatar's home grid will
be holding inventory and assets will be scattered on services as
that grid (and possibly user) chooses.
That said, nothing prevents a region from allowing its users to say
"Hey, Jacob [email protected]" should
be managed persistently here in a relationship with "Jacob [email protected]
" my identity here. I'm strongly in favor
of delegating as many of these choices as possible to the grids, and
the services they deploy and trying very hard to prejudge
what the grid creators and ultimately end users will want.
- David / Zha
[email protected] wrote on 01/07/2010 04:55:25 PM:
> [image removed]
>
> Re: [Opensim-dev] OGP module and the grand re-factor...
>
> Melanie
>
> to:
>
> opensim-dev
>
> 01/07/2010 04:55 PM
>
> Sent by:
>
> [email protected]
>
> Please respond to opensim-dev
>
> Hi,
>
> the other night, Meadhbh told me that the persistent accounts were
> not intended. So that's cleared up.
>
> Melanie
>
> Cristina Videira Lopes wrote:
> > 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
> _______________________________________________
> 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
