perfsonar development work

[Loukik Kudarimoti <>]

Hi Michael,

Welcome to perfSONAR!

Michael Bischoff wrote:
> Jeff W. Boote wrote:
> > My main opinion here is "keep it simple". I say this as someone who 
> > does not look at the Java code very often, but does need to now and 
> > then. Additional complexity makes the Java implementation less and 
> > less useful as a reference implementation.
> >
> > Creating lots of directory hierarchies does not aid in maintenance or 
> > comprehension of the code. And, the directory hierarchies are 
> > completely irrelevant to the functionality - so it is largely 
> > unimportant except with regard to maintenance and comprehension.
> >
> > Loukik's proposal looks to be the most simple at this point. Roman, I 
> > would personally not add the service directory level. For example, 
> > pS-UI might well create a service interface some day to allow for 
> > tests to the desktop - or tests between two clients. Who knows?
> I agree with most of the above I disagree with the service directory 
> part. In the line of thinking (keeping things simple), I think that 
> using the motivation of  'might be some day'  is a bit wrong.  In a 
> sense that merging it all in one big directory wouldn't take much 
> effort for when that time is there. Also it would probably be loaded 
> into the client as some kind of component keeping it pretty separate 
> for the rest of the client code. Perhaps services could be reused even.

I understand what you mean Michael. I am not advocating one way or the 
other (on creating a /trunk/service directory) but I think there are 
couple of things to note:

* Services are already clients (of Lookup Service for example). So, its 
really not "in the future". It is already the case and will expand in 
scope (Authentication Service, Transformation service, etc)
The client related code which is 'common' will have to be in perfSONAR 
base (with the right package name).

* If the main purpose of having these /trunk/service and /trunk/client 
directory is to group the product source code so as to make it easy for 
new developers, I am not sure if it will be of much help. I expect that 
there will be a readme or a  wiki page for each product which will say 
what type of product it is and what are its functions (essentially 
achieving what the service directory will achieve).
> a side note: separation(directors) gives a clear indication with 
> respect to dependencies. Services for example should have cross 
> references with one an other (right?) There are other 
> techniques/tooling to check this and give feedback to the developer.
I don't understand how this relates to the /trunk/service and 
/trunk/client directories. Can you please explain?

The general rule should be that if a service developer of product x 
would like to make use of some source code/component used in product y, 
then:

* If the developer thinks that this is a one-off need (and does not see 
the component as eligible to be moved into a common code-base (i.e. 
perfsonar-base),
He/She can copy over the source code into their product, re-use it and 
support it as if it were there own code (some credits to the original 
author of the source code will be nice)

* If the developer(s) (borrower/authors) think that the component in 
question is eligible to be put into perfSONAR-base to be made available 
to a wider audience, then they can do so (but with communication with 
the person(s) in charge of perfSONAR-base.

* (If Product x is developed by the GEANT2 consortium), then the Product 
x should not *import* product y or components of product y directly 
without making this 'dependency' known to the release teams. This is 
because GEANT2 wants to provide support to its products. In order to do 
this, all dependency factors need to be known and taken care of


I like Maciej's idea of creating multiple jar files for perfSONAR base. 
We need to discuss on what basis this division into multiple jars can be 
made. We should also discuss the impact of this on release management of 
the perfSONAR-base product.

Thanks,
Loukik.

> > However, I do agree with Maciej's suggestion that it could be useful 
> > to break pS-base up into multiple jar files. I do not think multiple 
> > directory hierarchies at the top of base is required to do that. SVN 
> > directory structure and jar file contents do not need to have a 
> > one-to-one correspondence.
> >
> > In terms of jar file contents, you could define it functionally like 
> > Maciej suggested, or other ways might make sense as well. (Say - new 
> > features in one, normal api in another, deprecated in yet another.) I 
> > don't have a strong opinion on how the jar files are organized - but 
> > I do hope that you keep the directory structure as simple as possible.
> >
> > jeff
> >
> > P.S. You should take my opinion here as simply a request to keep it 
> > simple. It is really Loukik (as release manager) and the main Java 
> > developers that have the most at stake here. And as such, their 
> > opinions matter most. My main motivation is in being able to 
> > understand the Java code well enough to ensure interoperability.
> jar-to-directory is a pritty good point.
>
> Beeing pretty new to the project(and thus the discussion) perhaps my 
> comments should be taken with a pinch of salt.
>
> greetings,
> Michael Bischoff