Is looking promising; there is even a nice buildbot to check the progress. This is sorely needed by anyone using Plone right now, especially for me. Recently at nymag we've been implementing image management in Plone; the problem is that currently i'm using exiftool to get XMP data from a file. Sadly, this is not the best way to apporach the XMP situation for Plone Everyone Else (tm) seeing as at the very least a new python library for xmp based on Exempi is available. Caveat, only for Python 2.5. Granted, it's a C based library and ExifTool doesn't have that requirement but as far as implementation goes it's not something a unittest would need to be written for. As it stands; I still have to write unittest to accomodate ExifTool.
That aside I spent most of the last 24 hours trying to see if Plone could get rid of Exif.py. There is another tool i've been using for the last couple of weeks to do so written by Ivan Herman called xmp.py that actually finished what he started. It reads the XMP data of a freshly uploaded Plone object and applies that data to the object itself, from there it actually applies it to the file. However, this only works for gifs/jpegs and it simply won't be enough. Via standard RDF/XML and extractXMP I was able to do a return _searchXMLContent(finstance.read()) and kick the tag data back to Plone and it works well. As time is a factor it means falling back to ExifTool as the only option but I can't reliably sprint on metadata replacement until I can use a proper python library; in-fact even using the ESA's python toolkit is a stretch as it's based on a C api. My personal feelings are that Exif.py should be deprecated in favor for totally replacing that functionality with ExifTool or something else. So, in summary, ExifTool wins as the only lib with a cleanroom, no dependencies beyond perl, full-featured implementation for metadata across the board. No other lib can say this; none. In-fact, I wouldn't be surprised if anyone doing anything with Metadata for a large audience isn't using it. So it's worth the system call.
Here's a quick and dirty implementation if you are thinking about using ExifTool and Plone:
def getXMP(self, img=None, refresh=False):
"""Get XMP data from file
"""
cache = '_image_xmp'
if refresh:
setattr(self, cache, None)
xmp_data = getattr(self, cache, None)
if xmp_data is None or not isinstance(xmp_data, dict):
io = self.getImageAsFile(img, scale=None)
if io is not None:
try:
fd, fd_name = mkstemp();
stream = os.fdopen(fd, 'wb')
data = io.read()
stream.write(data)
exiftool_str = "/usr/bin/exiftool %s -CreateDate -Artist -Copyright -Creatortool -Creator -Usageterms" % fd_name
xmp_datab = Popen(exiftool_str, shell=True, stdout=subprocess.PIPE)
out = xmp_datab.stdout.read()
stream.close()
print out
#temp rename above to xmp_data and remove the below dict Chris.. this is yourself in the past telling you
# not to forget like a dumbass
xmp_data = {}
except:
LOG.error('Failed to process XMP data', exc_info=True)
xmp_data = {}
io.seek(0)
if not xmp_data:
xmp_data = {}
setattr(self, cache, xmp_data)
I came across this article post called Neutron Protocol: Separating UI From The CMS which discusses a protocol that exists for essentially allowing client access to the CMS so that developers may create a completely separate UI from that of data submitted/entered into the CMS. There is no problem with this except that it pretty much already exists in the form of XML-RPC. The author makes it seems as if this is a problem but indeed I believe the Neutron Protocol died because it simply wasn't needed. Right now, today, with Zope/CMF or Plone in general. I can expose any method/function/class/object that I want via XML-RPC and even provide get/set methods for data in the context it exists. So for example; if I want to get the top 100 models from a CMS install all I have to do is from zope.app.publisher.xmlrpc import MethodPublisher and derive a class with MethodPublisher as an argument. From here I can use whatever language I want to call these methods effectively allowing me to create a brand new UI. So this stuff is pretty simple using XML-RPC but it'll be interesting to see what if any thing comes of this. If it's light enough it could be useful as an interim to XML-RPC exposure of data/content. At the very least it'd be useful for developers who aren't necessarily intimately familiar with the codebase but want to have their own UI available for content.
Zope2 on Python 2.5, XMP and ExifTool
Is looking promising; there is even a nice buildbot to check the progress. This is sorely needed by anyone using Plone right now, especially for me. Recently at nymag we've been implementing image management in Plone; the problem is that currently i'm using exiftool to get XMP data from a file. Sadly, this is not the best way to apporach the XMP situation for Plone Everyone Else (tm) seeing as at the very least a new python library for xmp based on Exempi is available. Caveat, only for Python 2.5. Granted, it's a C based library and ExifTool doesn't have that requirement but as far as implementation goes it's not something a unittest would need to be written for. As it stands; I still have to write unittest to accomodate ExifTool.
That aside I spent most of the last 24 hours trying to see if Plone could get rid of Exif.py. There is another tool i've been using for the last couple of weeks to do so written by Ivan Herman called xmp.py that actually finished what he started. It reads the XMP data of a freshly uploaded Plone object and applies that data to the object itself, from there it actually applies it to the file. However, this only works for gifs/jpegs and it simply won't be enough. Via standard RDF/XML and extractXMP I was able to do a return _searchXMLContent(finstance.read()) and kick the tag data back to Plone and it works well. As time is a factor it means falling back to ExifTool as the only option but I can't reliably sprint on metadata replacement until I can use a proper python library; in-fact even using the ESA's python toolkit is a stretch as it's based on a C api. My personal feelings are that Exif.py should be deprecated in favor for totally replacing that functionality with ExifTool or something else. So, in summary, ExifTool wins as the only lib with a cleanroom, no dependencies beyond perl, full-featured implementation for metadata across the board. No other lib can say this; none. In-fact, I wouldn't be surprised if anyone doing anything with Metadata for a large audience isn't using it. So it's worth the system call.
Here's a quick and dirty implementation if you are thinking about using ExifTool and Plone: