FYI, the branch has been merged.
On 5/4/2011 7:17 AM, Diva Canto wrote:
The caps branch is ready to be merged to master. It would be great if
a couple of core devs would take a look before I merge it. Highlights:
- New section [ClientStack.LindenCaps] in OpenSimDefaults.ini that
allows the specification of where each capability is served from.
- New dll: OpenSim.Region.ClientStack.LindenCaps.dll. Contains all the
capability-related modules that were previously in CoreModules, except
one. The exception is CapabilitiesModule that is now in
CoreModules.Framework and that holds the generic dictionary of
per-client caps object and triggers the OnRegisterCaps event.
- New dll: OpenSim.Capabilities.Handlers.dll: contains some of the
handlers. I didn't extract them all because some capabilities might
never be served from anywhere but the simulator (?).
- The old Caps.cs (in OpenSim.Capabilities) has been slashed. It now
holds only a dictionary mapping capability names and to handlers. The
handlers themselves are in the other dlls.
From here on, the rule would be that any new capability of the Linden
viewer to be implemented in core would be, in principle, split into
the handler itself placed in OpenSim.Capabilities.Handlers.dll, and a
module that registers that capability with the simulator in
OpenSim.Region.ClientStack.LindenCaps.
On 5/1/2011 10:28 AM, Diva Canto wrote:
FYI, I pushed the new caps branch. Nothing in there works yet, it
just compiles. For the moment, it's a scratchpad, things are fairly
incomplete, and I expect it to go through a few major changes. If
interested, please take a look. Things worth noticing:
- The additional [ClientStack.LindenCaps] in OpenSimDefaults.ini.
This is how I envision making these services configurable. I took
that big list from here:
http://wiki.secondlife.com/wiki/Current_Sim_Capabilities (I
understand OpenSim doesn't provide for all of those) The idea being
that if that is set to localhost we do what we currently do, but if
set to a URL we use that URL string as is, possibly appended with the
authorization token when that mechanism works.
- The new OpenSim.Region.ClientStack.Linden, replacing
OpenSim.Region.ClientStack.LindenUDP, which now contains 2 parts: UDP
and Caps
- The new OpenSim.Capabilities.Handlers, which for the moment
contains only the GetTexture handler. I'm using that one as the model
for how to do this in general.
Again, things are incomplete. But I want to share this right now, so
that ppl have the chance to influence how this is going.
On 4/30/2011 7:44 AM, Diva Canto wrote:
I'm going to do this work on a branch called caps. This is mostly
refactoring, not new development; it can go through a few iterations
until we're all happy with the result.
On 4/29/2011 3:01 PM, Diva Canto wrote:
On 4/29/2011 2:37 PM, Melanie wrote:
Hi,
Caps as such are a a generic concept, they are not a Lindenism,
IMHO. Linden didn't invent them and I believe that the CAPS
mechanism as such should remain in the normal namespace.
The idea is generic; our implementation is not; it's full of
LL-specific things, like LLSD, and it is serving the Linden clients
specifically. Other uses of capabilities will probably look quite
different.
Also, modules already use CAPS, if CAPS were in the client stack,
they would be much harder to access,, since the client stack is
somewhat isolated from modules.
We can have modules in any dll. The proposal here is to move all
CAPs-related modules out of the core dlls, and have them in a
Linden dll, because they are designed to serve the Linden clients.
I believe that it should be possible to re-route caps to other
destinations, ROBUST or external servers, but not by moving all
handlers into the Servers namespace, that is not what it was meant
for. That would bloat and pollute it. This warrants more discussion.
I agree. We can place them in some other Server.Handlers-like dll.
How about OpenSim.Server.Capabilities.dll?
Crista
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
