Re: [PEPr] Images::Imagick proposal, Small Errors

Thorsten wrote: > Well, starting with respecting tricky cases would lead us into the question > about usability As I said, for usability considerations, you should really get inspiration from the IM Perl api, since there is a big amount of experience in it. > - there could be a neverending discussion about which errors should be > catched and which not. Since I am aware of the fact that errors may occur if > a user submits an image-name without a file-extension, I don't want to > handle this case. This a detail a admit. But what I was explaining was that this is one of the symptoms that shows that your design is not the best approach at all! The problem has to be taken uphill (/upstream?) from this ! > I have put a notice into the doc-block that the file-name > MUST have a file extension. > (Btw I don't know a case where a user would save an image without > file-extension. ) There are a lot. Why do you think IM handles such things? > However, if there will be more feedback about this I will think it over. Go to the IM community, a lot of feed back there to see what IM users do with IM !!! The Perl api has been designed due to a lot of feedback too. [...] > saved into the directory PEAR/Image/Filter/. file_exists() Does not know [...] just another suggestion: PEAR/Image/Magick/Filter/ would't it be better, since perhaps one day there will be other image manipulation api than the IM one, a GEGL one perhaps one day? So I think filters would be specific to each api. For exemple I have discussed with Dave Neary about an ascii based image description format, he was not persuaded (first that it should be an ascii arch format like in Scribus or OOo) and second that it should be shared genericly with IM. So that is why I made the choice to make MSL 100% IM standard rather than finding a generic approach based on the common points between Gimp and IM. :p