perfsonar development work

[Maciej Glowiak <>]

Jeff W. Boote wrote:
> Maciej,
>
> On Jun 16, 2008, at 5:02 AM, Maciej Glowiak wrote:
>
> > Jeff W. Boote wrote:
> > > On Jun 3, 2008, at 9:23 AM, Jason Zurawski wrote:
> > > > Cándido;
> > > >
> > > >
> > > > > > I think the request should be XML and not 'string' data. This 
> > > > > > would allow services/clients to use the full set of XML api's to 
> > > > > > look at requests/responses. (Otherwise, why are we messing with 
> > > > > > this bloated XML stuff anyway?)
> > > > >
> > > > > Yes, I agree with you but I don't know how to do it. I can have the 
> > > > > Document or the String of the <Request> element but how I integrate 
> > > > > it in a nmwg message? I guess I should use the 
> > > > > org.ggf.ns.nmwg.base.v2_0.Element class but it wasn't work.
> > > > > So, any help for adding the <Request> element inside an 
> > > > > <aa:subject> element? :-)
> > > >
> > > > To do this you would need to add the necessary objects and handlers 
> > > > to the nmwg object structure.
> > > Or stop using the object marshaling model and just use dom directly 
> > > or perhaps a push-pull model... Not sure where that is on the Java 
> > > developers plans, but the marshaling model has obviously shown itself 
> > > to be a pain in more ways than one and I don't think we should be 
> > > crafting message formats due to this implementation limitation. 
> > > (Especially given the fact that the main Java developers have already 
> > > expressed the wish to remove it.)
> > > Probably the short-term solution in the Java implementation is as 
> > > Jason says: Add the needed objects into the nmwg library.
> >
> > Hi,
> >
> > In psBase2 the NMWG implementation will be DOM-like, so all 'unknown' 
> > elements will be stored (or not) into generic Element.
> > There will be more options to store such requests (just a string), 
> > etc. so I think the best 'short term' solution is leave it as is and 
> > wait for psBase2.
>
> The message for Candido is new development - I think it is a mistake to 
> define new message formats with non-XML content inside them (this makes 
> these messages more difficult to work with in standard parsing 
> libraries) due to a limitation in only one of the parsing 
> implementations. This is not just server side - it is all clients as 
> well. Especially since a work-around has been identified for that one 
> problematic implementation.

Fully agree, but we're limited by the implementation, so until we do not 
change it, we have to use it. The simplest solution is sending it as a 
string, although I agree it looks unreadable and strange. We should 
consider it as temporary and look forward for changing it as soon as the 
implementation allows.

Anyway, if there are only few non-NMWG elements, they should be of 
course implemented as an extension to NMWG jar, otherwise we should wait 
for new base2 implementation.

Maciej

--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024          -- skype_id: maciej_psnc   GG: 4526858 ||
 ====================================================================