perfsonar development work

["Jeff W. Boote" <>]

Fausto Vetter wrote:
> Hi,
>
> If you assume a point of view, it does not matter if it is the schedule 
> or the tool point of view, any n-to-n relationship will end up to be an 
> n-to-1 relationship.

True.

> For example:
> - one specific tool may be addressed to a different number of schedules
> and the same the opposite:
> - one specific schedule may be addressed to a different number of tools
>
> So, this end up to be an n-to-n relationship, so to give more 
> flexibility, use n-to-n concepts.

We are discussing a specific point of view. The point of view of the requester, 
right? What other point of view is useful? (That was the jist of my question 
when I asked for examples where exploiting the n-to-n relationship would be 
useful.) Adding this full generality is more work, so we should have use cases 
that would justify that added complexity.

Specifically, for the two examples above:

I do not really see a need for one specific tool to be addressed to a number of 
different schedules. In general - each of those different schedules will be done 
on behalf of different users and the data will need to go to different places. 
And most likely, the tool itself will be run with different options.

Likewise, I see users wanting to control each individual submission to the 
scheduler for a specific tool independently. Not as a group. I already mentioned 
the potential AAA issue with grouping in the previous email.

jeff

> Jeff W. Boote wrote:
>
> > Fausto Vetter wrote:
> >
> > > Hi,
> > >
> > > Since tool and schedule has an n-to-n relationship (if we think in 
> > > database concepts :) ), I guess the best way to do is to use 
> > > metadatas like bellow:
> > > - tool metadata
> > > - schedule metadata
> > > - metadata to join tool and schedule
> >
> >
> > Interesting idea, but I'm not sure we really need the full generality 
> > of an n-to-n relationship.
> >
> > I always thought of this as a n-to-1 relationship from the point of 
> > view of the scheduler. It has n entries in it's table of received (and 
> > approved) requests, and each one of them has a single 'measurement' it 
> > needs to perform using that given schedule.
> >
> > Can you give examples where extending this to an n-to-n relationship 
> > would provide benefit? I can see it would be easier to group multiple 
> > measurements under the same schedule.
> >
> > However, I don't see a clear benefit to that over having the client 
> > make multiple requests to the scheduler. In fact, it would complicate 
> > the deletion of a single one of those measurements - and could be more 
> > complicated in the AAA process (what if an owamp measurement is ok, 
> > but the bwctl one is not?).
> >
> > jeff