abstraction of mapogcsos.c common ogc bits

[Yewondwossen Assefa]

Daniel Morissette wrote:
> Kralidis,Tom [Burlington] wrote:
> 
>>
>> What do people think about a generic mapowscommon.c / mapowscommon.h
>>
> 
> I think that grouping all OWS Common stuff in a mapowscommon.c file 
> would be a good idea.
> 
>>
>> Maybe Assefa/others can provide comments on using libxml2 compared to
>> msIO_printf for XML.  If it were up to me, I'd go with doing things the
>> libxml2 way, as msIO_printf can be quite error prone for XML output and
>> well formedness.  This would of course mean that any future development
>> of OGC stuff in MapServer would be best to align with the libxml2 way of
>> doing things.
>>
> 
> It seems that using libxml2 for future OGC service work is probably a 
> good idea, but I think we'd need some comments on whether libxml2 
> brought real benefits for the SOS implementation by simplifying the 
> code, and also it would be interesting to see a comparison of the 
> performance impact of using libxml2 vs msIO_printf.
> 

  I think we did have this discussion a while ago about the advantages 
of using libxml2 vs msIO_printf (could not retrieve the thread or was it 
on IRC ?).
  At the time of implementation,  my feeling was It considerably 
simplify the xml output management (validating, closing tags, name 
spaces ...). It also make it a lot easier to maintain (such as adding 
new elements ).
  As for performance, I have not done any comparing between the 2 
systems. It would suspect that using libxml2 should be slower but then 
again most of the time consumed when doing ows requests is not in 
generating the xml but actually doing the server side request (queries 
...). So the overall result for the end user might not be that 
different. I personaly rather have a maintainable code in a long term 
using libxml2 (or other lib) if it does not add that much time to the 
end result. Having worked in wms/wfs, I always found that things like 
formating was kind of painful and was a bit scary too for someone new to 
get into the code and do modifications.

Of course there is the dependency of using another library and also the 
time that we need to spend to restructure wxs code without any gain in 
term of functionalities that must be taken into account.


> I guess before deciding to go with libxml2 all the way I'd like to make 
> sure that we are not trading an ugly mechanism for another ugly one with 
> just poorer performance.
> 
> For instance, from a quick browse of the mapogcsos.c code, it seems that 
> everytime something is set with libxml2 there is a call to xmlNewNs() 
> with hardcoded namespace and uri. There is a total of 110 calls like 
> this in mapogcsos.c, most of them with the same hardcoded gml or ows 
> namespace info, are these really necessary? Do these repeated 
> allocations of objects not add up and eventually impact on performance? 
> If they cannot be avoided then at least we should use a #define to avoid 
> duplicating the same namespace and uri strings 39 times (for ows) and 25 
> times (for gml)... at least to make the code look better than the former 
> msIO_printf version.
> 

Actually functions to create an xml node take the name space as argument 
( xmlNewChild, xmlNewNode). At the time I was implementing, It did not 
work as advertised in the doc.  I have not tried with latest versions of 
the library but It works It would simplify things.

> Please don't get me wrong, I'm not saying that libxml2 is not a good way 
> to go, I'm just thinking out loud.
> 
> Daniel




-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------