Mike,
That's an interesting statement to make, considering that John Hurliman
and I are working on writing up the *working* Hypergrid 1.5 as a
proposal to VWRAP, since we have both concluded that the concepts being
talked there lately, without any implementation behind them, are
essentially indistinguishable from the working HG 1.5 that lots of
people are already using.
It seems that you are trying really hard to make this look like a war
between OpenSimulator and VWRAP. I don't think that's the general
feeling in VWRAP, I think it's just you. The proposal to VWRAP will
happen. Hopefully, most people there will be able to assess the
technical issues, independent of the political ones. (emphasis on
*hopefully*)
Diva / Crista
Mike Dickson wrote:
Fine, then do what you like. The code's all available. If I don't like
it I can change it. Of course that sort of shoots holes in
interoperability. But then I didn't feel that hyper-grid belonged in
core either for the same reason.
I think you've way over trivialized the whole set of interactions
between agent, asset and simulator services in situations where those
services are defined by different principals. As Meadbh said, this
feels like optimizing to solve a specific problem before you've really
looked at the larger issues. It might be instructive just to simply walk
through some use cases and see where things fall apart. Alot of that
discussion has already taken place on the VWRAP list but OpenSim core
seems to be dead set against involvement in that.
I don't see a way to contribute here beyond the opinion I've already
voiced so I'll drop this.
Mike
On Sun, 2010-08-29 at 22:56 +0000, Melanie wrote:
Sorry, i disagree. The information included is defined by the
REQUIRED data on the recipient, not on what data the sender wants to
provide. the recipient NEEDS a displayable field. It can't be optional.
Melanie
Mike Dickson wrote:
If the decision is to go ahead and do cache-able data then I'd agree, do
it as attribute NVP's and make them optional. The originating agennt
service is then free to define the semantics of the attributes it
exposes.
Mike
On Sun, 2010-08-29 at 21:42 +0000, Ai Austin wrote:
From: [email protected]
protocol://authority/resource_type/resource_id[/cacheable_data]
+1
consider ensuring that at least the name is provided in a form that
can be resolved fast and locally by including the avatar
firstname+lastname - in whatever form the providing grid wishes to
address issues raised by others - so long as the strings are "legal"
in the creator/owner fields.
would it be worth making sure that the "cachable data" is in the form
of keyword=value pairs, and hence put in a "parameter" form after ?
rather than a final /?
protocol://authority/resource_type/resource_id[?key_value_pair[,...]]
with a minimum suggested (or
required?) avatarname=firstname+lastname if the resource_type = user
_______________________________________________
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
