CSW connector refactoring
A WMS connector was refactored in PROXY 2.2.0 (http://forge.easysdi.org/projects/proxy/versions/80).
CSW connector should be refactored as well.
#4 Updated by Van Hoecke Hélène almost 8 years ago
Refactoring CSW connector will not lead to a major performance improvement.
The only process that will be improve by the refactoring is the response rewriting, by using JDOM in place of XSL transformation. Time will be save on this, but this is not the most time consumer process in the CSW connector.
and sorry for the delay...
#6 Updated by Van Hoecke Hélène almost 8 years ago
For a GetRecords request, it's the construction of the filter for the authorized metadatas.
For GetCapabilities and GetRecordById, there is no really time consuming process, so refactoring can give improvement.
(my previous answer was not really clear and right, i just thought to GetRecords)
#8 Updated by Magoni Bruno over 7 years ago
- Assignee changed from Van Hoecke Hélène to Mérour Xavier
Just let me snake here ;-)
I guess that working only on GetRecords request to improve performance is not sufficient...
For now CSW connector is not refactored and it will be more unconvenient to upgrade small part of it instead of reengineering it's full code.
When refactoring, we will gain access to stability and clarity of already refactored PROXY common code (done with WMS and WMTS).
In my opinion, it's important using JDOM instead of XSL transformation for performance but also for stability and maintenance stuff!
Bringing coherent source code to Community is very important for new developers who want/need to add feature or fix bug.
In this way, WFS will be the last connector to be refactored.
We must keep in mind that building filter will be not necessary anymore in the future (short or middle time, I still don't know) as EasySDI properties won't be stored into MySQL database but inside metadata content. So playing with filters will be thrown away...
#9 Updated by Mérour Xavier over 7 years ago
- Assignee deleted (
If XSLT is widely used in current CSW connector, according to what you said Bruno, it's still relevant to work on CSW refactoring to move from XSLT to JDOM I guess.
I am just not sure to see exactly the gain moving to JDOM when talking - strictly - about performance.
#10 Updated by Magoni Bruno over 7 years ago
Before refactoring, PROXY was building dynamically the XSL file to finally apply it on XML content sended back by distant OGC service.
After refactoring, PROXY is directly manipulating XML content with JDOM API. This way to do is much more convenient for manipulating XML node (source code is more readable and it's very time saver when adding new XML node transformation) and offers much performance during XSL transformation (JDOM manipualtion is faster than XSL transformation and we don't need anymore to prebuild dynamically an XSL content).
Hope it helps understanding the difference between XSL and JDOM :-)