perfsonar development work

[Loukik Kudarimoti <>]

Dear all,  to summarize, I can list out three options:

1. Introduce an arbitrarily named field. The value of this field will 
have to be an URI.
Example: <nmwgt:project>http://geant2.net</nmwgt:project>

2. Introduce a keyword field as suggested by Jeff, Aaron...
Example: <nmwgt:keyword type="project">http://geant2.net</nmwgt:keyword>

3. Introduce a parameter field
Example: <nmwg:parameter name="project">http://geant2.net</nmwg:parameter>


Within the scope of the RRD MA and SQL MA interfaces and store messages, 
any of the options listed above can be present inside
- either inside the interface element
- or at the top of the message, at or inside the top level parameters 
element (if there are 1000 interfaces, this will avoid having to place 
this tag in each interface)
- or both (to facilitate overriding - in case of 1000 interfaces, if a 
majority of them belong to one project and a minority belong to another 
project, this will still save some effort and space)

Since we have this feature introduction marked out for 3.1, we need to 
reach a consensus pretty soon. My default preference is to go with 
option 3 as it seems to involve least effort!

Can you let us know of your preference latest by tuesday, 3rd of June 
please?

thanks,
Loukik.


Jeff W. Boote wrote:
> 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


--

---------------------------------------------------------------
L o u k i k   K u d a r i m o t i

     * *              Network Engineer
   *     *            City House, 126 - 130, Hills Road
  *                   Cambridge CB2 1PQ, United Kingdom
  *                   WWW: http://www.dante.net
D  A  N  T  E          Tel:+44 1223 371300 Fax:+44 1223 371371