I am always a bit skeptical about these approaches (i.e. providing a
general wrapper) because you either have to agree on the least common
denominator of features or have to implement features in the wrapping
layer. In any case the wrapping layer needs to be updated whenever one
of the backend changes, which potentially creates a lot of maintenance
You are right about this. I think if there are issues, we will need to make one or the other a prerequisite. For now, it's a case that we are moving out of REXML... but haven't decided if we want to force the dependency on ox.
Also, especially with REXML in the mix I believe that had some quirks
related to encodings in the past. So generally testing effort will be
quite high. My 0.02€.
Thanks! As above, REXML works for us... so, hopefully, the rest is easier still. Also, we are currently only parsing an XML file, so it might be easier still.
If only a few operations are used then the situation might look
different. Still you add one dimension to the test matrix because you
have to test all target system configuration combinations.
Yes, it is only a few operations. But you make an excellent point.
I think I have seen nokogiri mentioned a lot and if we were using Nokogiri, perhaps, I would have cared less. Just that ox seemed less popular but worked very well (and very fast) for our scenario. So, I was unsure if I should force that dependency also because ox installation is a bit difficult on Windows which is where we use it most.
On 2019-4-1 5:33 PM, Robert Klemme wrote:
On Sun, Mar 31, 2019 at 11:54 AM Gerald Bauer <firstname.lastname@example.org> wrote: