perfsonar development work

[Roman Lapacz <>]

Loukik Kudarimoti wrote:
> Hi guys,
>
> I am trying to avoid commenting in-line because this email is getting 
> quite long. Here is a summary of what I want to say. I think we should 
> discuss specific points below, get an agreement and move on to the 
> next point.
>
> *1*
> - All source code used commonly (or expected to be used commonly) 
> across one or more services and/or clients will have to be grouped in 
> perfsonar-base. These should be released as a jar file for import in 
> per service development along with api documentation.
>
> - Before adding new source code to perfsonar-base, the person(s) 
> in-charge of perfsonar base maintenance will have to be contacted.
>
> - This is a support related constraint. If any of the products are 
> using shared code, we have to work on support for that shared code. If 
> the shared code is all over the place (i.e. many locations other than 
> a single perfsonar-base), its very difficult to work which development 
> teams we are dependent upon. Its much easier if we have it as one 
> product (i.e. perfsonar base)

I would prefer to have the base which is very generic (for services and 
clients; interfaces, utility classes) and does not have the 
implementation directly connected with specific service type 
implementation. This could be a light framework easy to understand by 
new developers.

But I see your point. Such base might need many libraries for 
compilation but some of them would not have to be used to compile and 
run a service Thus some of them which are useless, for example for MA, 
would not have to be put in the installation package of MA. This 
approach could be accepted by me.

Maciej which solution you prefer?

> (This is what was discussed in January 07 workshop)
>
> *2*
> I don't have a strong opinion about creating a trunk/services 
> directory and having all services put in there. I am not in favor of 
> it but don't oppose it either.
> The important question however is...there will be clients which will 
> act as services as well. Where will these fit?

In SOA the service usually have both functionalities: server and client. 
But it's still a service. You could ask will our client applications be 
pS services (for example, perfsonarUI)? I don't think so.

> *3*
> Creating service family (MA, MP, etc) directories inside 
> /trunk/service (or under trunk) will not scale.
> - There will certainly be services which will act as both MA and MP or 
> more (for example, MA and transformation). Where will these fit?
> - I don't like this idea.

You right. We could have just 'service' directory. Hmm, this strengthens 
the argument to use the bundle with all base stuff (even service specific)

> *4*
> Service naming convention - we need one. We all agreed to using one in 
> the last january workshop. It wasn't a strict naming convention but 
> sufficient to get enough information made available by the developers 
> in a name.
>
> The development teams can still choose the names for their products 
> but have to provide required information in the name.
>
> (This was already agreed in the last workshop. To avoid re-discussing 
> the same issue again, if anybody wants to change this decision, he/she 
> should make it clear as to why this (re-)discussion is required. I 
> haven't seen a strong reason for not following this naming convention)

As I wrote in one of my previous emails. I wasn't stuck to presented 
names of service directories (it's up to service developers and naming 
convention).


Roman