perfsonar development work

[Yee-Ting Li <>]

Hi all,

> > Perhaps we - all participants who use or provide perfSONAR  
> > services with
> > PERL - could collaborate in some way to avoid having the same
> > developments twice or three times (as now).
> That would, of course, be a wise course of action!

Agreed; however, i think it would be important to stress that we work  
on the common components rather than creating an entirely new  
framework for everyone that does everything (as it's very difficult!).

I like the list by Jochen, and i think it's a good start to identify  
the main areas. however, the way i see 'perfsonar' is that it is a  
web service which strictly speaks NMWG between clients and servers.  
as you guys have already mentioned, it can be as simple as sticking a  
http listener that spits out nmwg. (soap or not)

i'm sorry for the confusion; i don't think that porting the java  
'perfsonar' api is a good idea; ie how the service handles the  
request once it has recieved a nmwg document (like using ibatis in  
java etc). there is way too much complexity in there for the average  
perl coder.

what i specifically had in mind was to port only the java NMWG  
libraries over to perl. as the nmwg spec changes, it should be  
important that existing (perl) services can easily 'update' to the  
latest xml spec. this was the main intention of my original request.

the other benefit is that if we were to build an api to the nmwg  
libraries, it would also separate out the need to fix to a particular  
perl xml library. so specifically; taking from Maciej's recent email,  
to create a new nmwg doc; we simply:

        my $message = Message->new();
        $message->setId("anId");
        $message->setType("LSRegisterRequest");

        my $metadata = Metadata->new();
        $metadata->setId("serviceLookupInfo");
        $message->setMetadata($metadata);

        my $subject = Subject->new();
        $subject->setId("commonParameters");
        $metadata->setSubject($subject);

        (etc)

of course, we don't actually need to do anything like this for the  
server end (except for creating the <data/> elements); but we would  
need a SAX parser to form the incoming xml to the above objects. so  
the real question is how to query for the metadata information so  
that the backend of the server can make the relevant sql/rrd/etc  
requests.

you're probably wondering 'what's the point given that xml::parser or  
xml::simple could do this trivially'... i'm not really sure! (which i  
was why i sent out the email). however, as Jochen said in his reply  
about the being accessing specific parts of the dom directly, i guess  
that this java-perl nmwg library would provide the functionality so  
that we wouldn't have access the dom directly. in fact, from this  
perspective, it could simply be a wrapper around the nmwg dom -  
rather than having all these objects everywhere.

however, i'm sure there will be a need to write perl clients that do  
not read in a xml file for the request, but to construct it  
dynamically - these object classes for nmwg (based upon the java  
ones) would be a nice way to provide that.

Yee.