perfsonar development work

["Jeff W. Boote" <>]

On May 23, 2008, at 2:34 PM, Joe Metzger wrote:

> I like it.
>
> How will it be handled by the LS?

Actually, that is where the idea came from. We were discussing the  
need for the LHC community to be able to find 'services' of interest  
for them and were thinking about ways of having user defined metadata  
for the service in the LS to support that.

We are still thinking about how this could be done, so I don't know  
that I can give you specific things yet.. Mostly we have been talking  
about the problems this brings up and ways to mitigate them. (If the  
keywords are not constrained/structured enough, everyone comes up with  
different ones and they become useless. And if they are not flexible  
enough for end users they likewise become useless.) Basically, we  
talked about limiting the number of keywords that any service could  
register as a way to deal with it. But as I said, it is only half- 
baked at the moment.

jeff

> On May 23, 2008, at 3:24 PM, Aaron Brown wrote:
>
> > An approach jeff suggested was to allow people to define 'keyword'  
> > elements in the interfaces. These elements would contain strings  
> > that you could search on. This could then be used for things like  
> > project names and the like, and would be allow people to easily  
> > define their own, and since it's a keyword, it's expected to be  
> > something abstract to search on instead of topological or test  
> > description information.
> >
> >         <nmwgt:interface>
> >              ... interface description ...
> >             <nmwgt:keyword type="project">IN2P3</nmwgt:keyword>
> >             <nmwgt:keyword>Internet2</nmwgt:keyword>
> >         </nmwgt:interface>
> >
> > What do people think about that?
> >
> > Cheers,
> > Aaron
> >
> > Joe Metzger wrote:
> > > Szymon & Loukik,
> > > I have been looking at this and I have realized that the
> > > URN's are not quite as flexible as I thought.  There is a domain  
> > > field
> > > in the URNs, but it should probably not be overloaded to include  
> > > project
> > > information.
> > >
> > > So, I have come to the conclusion that we do need an extension to  
> > > handle
> > > this capability.
> > >
> > > --Joe
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On May 23, 2008, at 5:59 AM, Szymon Trocha wrote:
> > >
> > > > Loukik Kudarimoti wrote:
> > > > > Joe Metzger wrote:
> > > > > > Loukik,
> > > > > > I don't think we need this.  We have already discussed putting  
> > > > > > URN's
> > > > > > into the protocol. These URN's contain a domain field. So, I  
> > > > > > think we should
> > > > > > just implement the approach that has already been discussed,  
> > > > > > instead of
> > > > > > inventing a new one.
> > > > > > Or, does this new proposal support some capability that URN's  
> > > > > > don't support?
> > > > > Hi Joe,
> > > > > I might have missed this point. URN is a great idea and I am  
> > > > > fine with using that approach. However, I am not clear where  
> > > > > such a URN will fit within the store file and the protocol and  
> > > > > how it will help us achieve the objectives discussed in Zagreb  
> > > > > and detailed for implementation below.
> > > > > Can you please explain with some examples?
> > > >
> > > > Hi Loukik,
> > > >
> > > > How is this specification progressing?
> > > > Joe - can you give us some examples of using URNs?
> > > >
> > > > Regards,
> > > > --
> > > > Szymon Trocha
> > > >
> > > > Poznan Supercomputing & Ntw. Center ::: NETWORK OPERATION CENTER
> > > > Tel. (+48 61) 8582022
> > > > http://noc.man.poznan.pl  ::: http://noc.pionier.gov.pl