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
