Very great you take this project in hands.

I'm wondering if PHP is a good solution. Not because of the language but because iguess it would be nice (one day) to have an internal gimp Plug-in registry browser. That would be much more usable for users, especially new users : just write keyword => list is displayed => Click to install.

In this case, could PHP easily interface with a such thing ? I don't have the answer ;) But such a plu-in browser could be done in python, so it could easier the have both in it ?

pygmee

cedric GEMY wrote:

I'm wondering if PHP is a good solution. Not because of the language but because iguess it would be nice (one day) to have an internal gimp Plug-in registry browser.

The coding behind the plug-in registry would have no bearing on any GIMP plug-in or built-in feature that allowed a person to search the registry. Any such feature in GIMP would only need to pass the query to the web site and parse the HTML code it received and present the results to the user.

The web site could take an optional argument in the query to allow it to present its output in a more easily parseable manner for use by a GIMP plug-in/built-in but this should still no bearing on how the registry is created.

Hi,

On Fri, 2007-02-16 at 18:10 -0500, Kevin Cozens wrote:

The coding behind the plug-in registry would have no bearing on any GIMP plug-in or built-in feature that allowed a person to search the registry. Any such feature in GIMP would only need to pass the query to the web site and parse the HTML code it received and present the results to the user.

The plug-in registry should offer a well-defined XML-RPC interface. No one should have to parse HTML code. That's a requirement if we want to integrate the registry with GIMP.

Sven

Hi Devin

Devin Watson wrote:

Hello everyone. I have been in chat in #gimp about this for a few hours today, and so far have had some mixed responses. I am volunteering my time to create a new GIMP Plug-In Registry and have been assembling some code and new database for this work.

However, it should be noted that the mixed responses I have received have been to the fact that I am building this in PHP. I was reminded by one of the members in #gimp to put these questions forth to this list:

- Do you want a new system built?

- Is PHP/MySQL acceptable?

- Having done a good share of the work already, would it be useful to anyone to try this once it is ready if they are skeptical?

I have the documents from the last Google SoC which outlines the proposed database and feature set, and I can honestly say that the database is not a problem, nor are the features that were requested. It would be nice to see the community get something good out of this and I, an avid user of GIMP, would like to give something back to the community that helps build this.

I don't have anything to say about choice of language, but here's some advice:

- Having you do this is awesome :) - Don't over-engineer.. simple systems are easier to follow and maintain - Make sure your system is reliable, then efficient

It's easy to go astray in a language that allows it and most web apps I've seen are structured like crap (especially PHP ones). Sven has also indicated that any interaction of the GIMP app with the web service should be via a proper RPC call. Write your system to be modular, maintainable and extensible:

- Use an OOD (PHP supports it) - Nicely encapsulate your application logic from the presentation (this lets you have RPC and website use the same backend) - Use a templating system (even if you're pre-generating static pages).. this lets non-coding UI designers make UI changes, and also lends itself well to the previous point
- Document all your classes and methods

This may seem like business-speak, but it makes things easier to follow, maintain and extend. You should also write test cases if you feel they're a good idea :P Provide an RPC interface anyway (SOAP or XML-RPC).. GIMP can use libsoup.

Kind regards,

Mukund