Savaging Adobe's XMP-SDK
This is an official "commercial" API/SDK from a very respected company producing "high quality" software. So far, it has been adequate quality rather than high quality.
The first problem I encountered was that it isn't GNU friendly, in that it lacked a configure script. This means I need to go digging in documentation to see how to build it. Fortunately there was a Visual Studio solution file, and once I had loaded it into VS (and fortunately I had the right version), it built okay. The use of third-party libraries went pretty smoothly. The problem is that the documentation is strewn all over the place in a variety of txt, HTML and PDF formats. What I really need is a step by step idiots guide, not because I am an idiot (I hope), but because I am busy and do not care to understand a new build layout.
There was also no example code, and no tutorial. You just get the methods documented. Both of these would have helped a lot.
There was a slightly unconventional inclusion of XMP.incl_cpp - a way to get templates to compile. Not bad, but this information was buried in the documentation (which I am too busy to read), hence I wasted a lot of time.
I really like a single XMP.hpp file included, but there is include hackery. This information is also buried in Doxygen comments, and it is pretty ugly to require two macros. Instead of saying #include, I need to write #define XML_INCLUDE_XMLFILES 1. Wrong-headed. I also need to #define WIN_ENV. I just shouldn't need to do these things.
You also need to pre-declare TXMP_STRING_TYPE for some reason - which completely negates the benefit of using templates. I could just write typedef std::string xml_string_type.
My next issue (due to lack of tutoral) is a strange assertion which I trace back to me not calling TXMPFiles<>::Initialize(). Argh. This is to initialize global state (which is evil). I also notice that all types start with a T. Not a C, a T. There is no namespace. Names are in CamelCaps - fine but not C++ standard. Finally I notice the opportunity for two-phase initialization (or 3-phase, if you consider TXMPFiles<>::Initialize()). Errors are indicated with return values, not exceptions.
In conclusion, this is falling into all of the old C++ traps that I would have imagined that modern libraries (and this library has been revamped fairly recently) should have avoided. It is clearly a C/C++ hybrid. Commercial software 0, open-source 1.
The first problem I encountered was that it isn't GNU friendly, in that it lacked a configure script. This means I need to go digging in documentation to see how to build it. Fortunately there was a Visual Studio solution file, and once I had loaded it into VS (and fortunately I had the right version), it built okay. The use of third-party libraries went pretty smoothly. The problem is that the documentation is strewn all over the place in a variety of txt, HTML and PDF formats. What I really need is a step by step idiots guide, not because I am an idiot (I hope), but because I am busy and do not care to understand a new build layout.
There was also no example code, and no tutorial. You just get the methods documented. Both of these would have helped a lot.
There was a slightly unconventional inclusion of XMP.incl_cpp - a way to get templates to compile. Not bad, but this information was buried in the documentation (which I am too busy to read), hence I wasted a lot of time.
I really like a single XMP.hpp file included, but there is include hackery. This information is also buried in Doxygen comments, and it is pretty ugly to require two macros. Instead of saying #include
You also need to pre-declare TXMP_STRING_TYPE for some reason - which completely negates the benefit of using templates. I could just write typedef std::string xml_string_type.
My next issue (due to lack of tutoral) is a strange assertion which I trace back to me not calling TXMPFiles<>::Initialize(). Argh. This is to initialize global state (which is evil). I also notice that all types start with a T. Not a C, a T. There is no namespace. Names are in CamelCaps - fine but not C++ standard. Finally I notice the opportunity for two-phase initialization (or 3-phase, if you consider TXMPFiles<>::Initialize()). Errors are indicated with return values, not exceptions.
In conclusion, this is falling into all of the old C++ traps that I would have imagined that modern libraries (and this library has been revamped fairly recently) should have avoided. It is clearly a C/C++ hybrid. Commercial software 0, open-source 1.
posted by Calum Grant at
5:51 pm
|
0 comments
