Hi again Ray,
Ray Plante wrote:
> Hi John,
>
> On Fri, 17 Nov 2006, John Taylor wrote:
>
>> First up, apologies for the delay in replying to this. There is A Reason
>> behind the choice of ivoids as messages. They're meant to be unique, so
>> using a URI seems to be reasonable. Why a registry URI? Well, we think that
>> there could be a benefit in registering the messages as separate resources.
>>
>
> I believe you can do all of this with the syntax I recommended, e.g.
>
> ivo://votech.org/plastic#info/getIVORN
>
> That is, you would be able to:
> o search the registry to discover the meaning of this message
> o search the registry for applications that support this message
> o have a tool interogate the registry to build a GUI for the message
>
> These capabilities would rely on:
> o there being registered a Plastic resource, of type "Standard" where
> the messages are defined.
> o there being tools that register their support for the messages
> (say as capabilities).
>
It's certainly an alternative worth considering, though I see two
problems: 1) we're already using the #fragment for something else 2) it
centralises the definition of messages in one place - we want to avoid
this. So far all the messages have been defined "with the votech.org
authId" (bad bad choice), but I'd really like to see
ivo://estar.org/voevent/do/something/funky appear at some point. Now
we'd be crazy to let Alasdair get his hands on our publishing
registry...so how would he add his message to the master list?
> The motivation for this alternative is to preserve two principles consider
> very important:
> o that you can, via a registry, dereference an IVO ID to a
> description.
>
Sure, I admit that it's a rather strange wrinkle if we don't end up
registering them. But...
ivo://surely ivo://you/dont ivo://claim/ownership
> o that the registry focus on course-grained resources, so that
> + we control the rate of growth of the registry, thereby
> controling the performance and maintanence costs
>
We're not talking about very many here in the grand scheme of things.
If you can detect a measurable drop in performance in your registry I'll
buy you a pint and some extra memory out of my next pay packet. OK, I
know, I know, it's the principle...if every tin pot little project
starts doing this we could be chest deep in VOResources before we know it.
> + we not confuse end users with a vast number of resources that
> are rarely of interest to them
>
I reserve comment on that one!
> + we not replicate the information content that is better managed
> by local providers and accessed through 2ndary services (e.g.
> SIA) (This point is item is less relevent to the plastic
> issue.)
>
Well, as you know, there are differing opinions on whether service
metadata is better accessed from the registry, the service or both.
> hope this clarifies things,
>
It does - I hadn't thought of the approach you suggested.
John
> Ray
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Plastic-devs mailing list
> Plastic-devs-at-lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plastic-devs
>
>
Received on 2006-11-20Z13:46:03