Is it possible to think a little bit outside the scope of your package?
i.e. as a way to get an unique IPTC package in PEAR?
This is not an IPTC package.
This is a full featured JPEG File Format package
That does involve IPTC information, as one of several blocks of information.
As such, this package already provides every single feature provided by Image_IPTC.
But for several reasons, one of them being the fact that this package is not just IPTC but the whole JPEG format, there is no simple way of implementing the IPTC portion of this package using the techniques from Image_IPTC.
The only way of putting the two packages together would be to kill Image_IPTC. And that would mean the loss of a fast targetted implementation.
I don't think it makes sense to add more complexity to an already very complex code (have you seen the code?) just to be able to "avoid duplication" where there is no duplication, just an intersection of orthogonal problems.
and more information than what the native extensions provide.
So in the end, we would have two almost independent implementations,
one using the native methods and one using php code. One allowing read
and write and one read only. It is just that those two implementations
would live in the same package. And that is not, at least not in my
eyes, justification enough to delay the current package and specially
not enough for the amount of work it would need.
XML_RPC does exactly that, and sounds like a very good thing. But the
point now, is to convince you to work with Patrick.
The way I see it is that there might be people for whom this library would be very useful as is. I already have it, so time doesn't matter
to me... but someone might be looking for a way to write EXIF
information, and that person would be affected.
That person can still grap the package from your respective site.
pierre