Re: Package Proposal: Image_JPEG
| From: | Pierre-Alain Joye | Date: | Wed, 07 May 2003 15:36:22 +0000 |
| Subject: | Re: Package Proposal: Image_JPEG | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-16016@lists.php.net to get a copy of this message | ||
On Wed, 07 May 2003 11:28:51 -0400
Sebastian Delmont <sdelmont@zonageek.com> wrote:
> I think the package itself might be very useful to those who don't
> have access to the latest PHP. So tying it to the exif extension might
> not be the best choice. At least not in the near future.
The goals is not to ty only on the extension (see the xml_rpc usage in
PEAR).
> And using the "native" extensions in my package is not that simple,
> because I need to provide the ability of writting the data back, so I
> need to get more information than what is needed for read-only access,
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?
> 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