perfsonar development work

[Nicolas Simar <>]

Maciej Glowiak wrote:
> Loukik Kudarimoti wrote:
>
> > Maciej Glowiak wrote:
> >
> > > Michael Michalis wrote:
> > >
> > > > Hi all,
> > > >
> > > > As you can see in svn report I've made some changes on the eXist 
> > > > admin servlet code and added two more properties in 
> > > > servlet.properties so I could deal with the problem of a not uniform 
> > > > way of naming properties in perfsonar services  But as it was 
> > > > pointed out by Loukik, this causes essentially a duplication of 
> > > > information. So it has been decided that  in order for the web admin 
> > > > servlets to work properly we are considering RRD MA properties to be 
> > > > the standard That is at least for eXist configuration(which was the 
> > > > cause of the problem so far):
> > > > component.ma.xmldb.db_adminpassword
> > > > component.ma.xmldb.db_uri.xmlrpc
> > > >
> > > > As from tomorrow the perfsonar-web-admin jar and build guide will 
> > > > roll back to their previous version and the RRD MA properties will 
> > > > be considered a standard.
> > > >
> > > > NOTE: Services don't have to use exactly the same name but they must 
> > > > have a common part that will allow the servlet to identify them 
> > > > successfully.
> > >
> > >
> > >
> > > Michalis, Loukik,
> > >
> > > 1. Names of properties to configure database are internal part of 
> > > service, they don't need to be common. If I am alone in this 
> > > statement, read next points:
> > >
> > > 2. There is nothing in the requirements for pS 3.0, the properties 
> > > must be common for all services
> >
> >
> > Maciej,
> >
> > Firstly, we are not blaming you or any other developer here. We are 
> > simply point out that something isn't being co-ordinated and the 
> > simplest solution is for it to be co-ordinated (instead of Michalis 
> > work taking the brunt of it).
> >
> > Michalis is doing development work (even though its on behalf of the 
> > release management team) and he has issues in working with the various 
> > products being developed. This is because not all of the common parts 
> > of all these products are being co-ordinated and made similar.
> >
> > This is not about what you think is internal and what you think is 
> > not. Its just about how difficult it is for Michalis to develop 
> > something common for all products and what is the best way out.
> >
> > Also, the perfSONAR 3.0 spec (or any other spec) is, at its state, 
> > meant to be a reference stuff not really a bible. Its not a document 
> > that contains release management's demands but rather, the entire 
> > project's plans for a particular release.
> >
> > Loukik.
>
> Anyway, the solution was good. It worked for me and for other services. 
> To be honest I do not like fully automated software, because it doesn't 
> work properly in half of "specific" cases. Configurable properties names 
> are fine. You may use it or not - then the procedure should try to 
> determine values automatically.
>
> I thought next step will be to "force" developers to change their 
> properties to common ones. That was my understanding of Michalis' e-mail 
> and your intention. If I misunderstood I am sorry.

If they are identical properties and if they are used by a component 
(like e.g. the admin pages), it would make sense to harmonise them.

Nicolas

> If understood well, you've already known what I think about such change :)
>
> Maciej

--
Nicolas
______________________________________________________________________

Nicolas Simar
Network Engineer

DANTE - www.dante.net

Tel - BE: +32 (0) 4 366 93 49
Tel - UK: +44 (0)1223 371 300
Mobile: +44 (0) 7740 176 883

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________