perfsonar development work

[Maciej Glowiak <>]

Jeff W. Boote wrote:
> So, what is the motivation for removing the structure?

Hi Jeff,

Thanks for your comments.

Motivation is:

1. Simplicity

    - use of one tag (parameter) instead of many others (simper to
      maintain)
    - no need of schema and implementation modification to add new
      parameters
    - all Lookup Info attributes are accessible in the same way

2. Flexibility

    - adding new Lookup Info attributes for new services is easy
      (because there is no need of schema and implementation changes)


The idea of using parameters is not new. As I said before, I remember we 
were discussing (or mentioning) it during one of our meeting. However it 
must have been quite a long time ago, because I don't remember where and 
when. Although nobody was against, we had already had the Lookup Info 
structure that time.

So, answering your questions:

>
> I personally think having good structure for the 'general' service
> descriptions is a very good thing. Especially when you consider the
> complexity parameters would add to xquery syntax clients would need to
> use to make queries of the LS.

XQuery will be even easier. It doesn't change anything, just the syntax. 
For example:

- //nmwg:metadata/nmwg:subject/nmwg:service/psservice:serviceName
- 
//nmwg:metadata/nmwg:parameters/nmwg:parameter[@name="serviceName"]

OK, 4 characters more... ;-)

>
> Is the motivation that you don't want to add more ggf elements?

Yes, that's the motivation; but not only -- see the beginning of my e-mail.


> If so,
> you might think about how this will effect your future DOM
> implementation. I suspect it complicates that.
>

NO, it doestn't change anything. DOM is the implementation. DOM is 
flexible, you may use both structures exactly the same. Id doesn't 
complicate anything (the structure is simpler in fact, so it may even 
simplify that)

> Now, I do think that using parameters could be a useful way to add
> service specific information. i.e. Extra information a service might
> want to register about itself that does not fit in the structured lookup
> information. But, things that are useful for all services to register,
> should be done in a well structured way in my opinion.

The new structure will be well structured. Initially I thought we could 
use mixed-type: fields we already have + parameters for new 
service-specitic attributes, but, doesn't it complicate the structure 
more than using just parameters? That was the idea - to keep it simple.

> I already gave my opinion of the general change. But, I'm curious 
about the specifics here as well.
>
> Why not just use:
>
> <nmwg:parameter name="supportedEventTypes">
>     <nmwg:eventType>eventType1</nmwg:eventType>
>     <nmwg:eventType>eventType2</nmwg:eventType>
>     <nmwg:eventType>eventType3</nmwg:eventType>
>     <nmwg:eventType>eventType4</nmwg:eventType>
>     <nmwg:eventType>eventType5</nmwg:eventType>
> </nmwg:parameter>
>
> I don't really see the reason to put another parameters container in. Or
> any reason to use a list of parameters inside this either.

Well, current implementation of NMWG classes doesn't support that.
The second thing, the structure I gave was already agreed. That was my 
understanding. It's difficult for me to send you what actually was 
agreed and when, because as I told before, I lost all my e-mail history. 
I was given the example of parameters in parameters from Roman, so maybe 
he could disclaim what actually was the decision.

For me your example is good as well, but I am not sure whether eventType 
is allowed inside parameter now.

I hope I clarified the vision.

Maciej

--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024          -- skype_id: maciej_psnc   GG: 4526858 ||
 ====================================================================