Hi, On Thu, 2006-06-22 at 13:33 +0200, Raphaël Quinet wrote: > Well, let's say that it makes it a bit easier if the code is at least > split in separate directories (even if a library is not required for that). > As for the lower overhead, it does make a difference if the file plug-ins > can link with a library directly or if they have to convert all data and pass > it through the PDB for every action, especially when these PDB calls have to > spawn a new process which in turn decodes the data, re-encodes it again for > the PDB (setting the parasite) and then only returns the result to the > initial plug-in. These 4 encoding/decoding steps and spawning of new > processes have to be done for every single property that is set or read by > the file plug-ins. As far as I understood your proposed API, the calls go through the PDB anyway. The API uses image IDs, so the parasite has to be retrieved from the core through the PDB, no? > To be frank, I thought that you agreed with the principle of moving the > metadata core into a library when we discussed it last time. I thought > that the discussion about the API would be mainly about the features that > the API should expose, rather than whether it should exist as a library API > or be limited to the PDB. I got a bit bored with the PDB implementation > and its limitations, that's why I expected to be more motivated to work on > the remaining issues after getting rid of the extra PDB calls. Last time we discussed this, I didn't expected you to wait with the move until we are about to freeze the APIs and start doing pre-releases. I have the feeling that you are pushing something into 2.4 that doesn't absolutely have to be in. But I may still be persuaded that we need it for 2.4. > I agree that such a notification feature would be useful for a lot of > plug-ins. However, my goal is really to have the metadata in the core, > handled like any other information about the image: resolution, colorspace, > image comment, etc. It would be very nice if we wouldn't handle all this in the core. Image comment could very well be handled by a plug-in. And color management is being deliberately kept out of the core. > You can probably argue that some of these features could also be > implemented outside the core, but then they would not be very well > integrated. For example, it would be difficult to select a default > license for all new images if this is not done in the main preferences. Ideally, plug-ins could register their configuration in the gimprc (to some extent they already can do this) and make it accessible in the Preferences dialog. We have already started to work towards this when we introduced libgimpconfig. The whole point here is however, do we need this library now or can it wait until after 2.4 has been released? That's the only question that really bothers me right now. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
