perfsonar development work

["Jeff W. Boote" <>]

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.

jeff