Jim Fulton wrote:
I replied to this privately. This has gotten so much discussion, I think I'd better clarify my position.

On Mar 14, 2008, at 8:27 AM, Derek Richardson wrote:

I am the Plone champion for the buildout builder. The buildout builder will be a web application, likely written in Grok, that will allow textually-challenged users to configure a buildout via a GUI and receive a .cfg in return.

Jim, you mentioned at PSPS-2008 that you would gladly help whoever championed this.

There was a misunderstanding or miscommunication.

Sorry about that.

I volunteered to help with a buildout-based installer. This is *much* narrower than a buildout-building GUI. My thought was that, for a simple installer, there could be GUI that asked the user some high-level configuration questions and then ran a buildout included with the software to set up instances. This is similar to what we're doing for deployments at ZC where we have high-level non-buildout configuration files that collect options that control instance installs. The instance installs are actually done by running buildouts.

I have about as much interest in a GUI to help me write buildout configurations as I have in a GUI to help me write Python scripts. :)

No, I don't think you're the target audience. ;)

I do see potential benefits of having GUIs or other automation tools to help people get started assuming that the scope of these tools is very narrow. They are only either to help people get started or for people who's needs will never be anything but simple.

The audience is the question. Plone seems to be moving to a buildout-centric model. We have developers who gladly use buildout (I am one of them); they will continue to do just what they do now.

We have some users who use installers. Some of them will always simply use installers and will be unaffected by the buildout builder. Some of them will decide, after they use the installer, that they'd like to tweak their install. Some of them will be text-comfortable and will move straight to modifying their buildout.cfg. Some of them will not be and the buildout builder will be a good incremental step for them - it will give them the ability to make simple, supported changes to their buildout without having to face a blank spot in their buildout.cfg and decide, ex nihilo, how to fill it. In this case, you can consider the buildout builder a web version of the buildout-based installer with GUI that you mention above.

A third category of user (in addition to buildout-mavens and installer-people), perhaps specific to Plone, are systems integrators. These folks may have considerable knowledge of Plone and technical skills in some areas, but may not be buildout-mavens or even know (or want to know) Python. They may be text-averse, not wanting to manipulate a buildout.cfg. They may not want to root through the Python code of less-documented recipes to figure out configuration options. They may simply want a less-steep learning curve. They may have complex needs that they understand from a system-administration viewpoint, but may not want to learn Plone behind-the-scenes, which includes buildout. I am not defending these people's choices to not learn buildout (or Python). The simple fact is that these people exist in sizable numbers in the Plone community and their needs are important. We heard from them loudly after the 3.0 release and at the PSPS. We need to address their concerns.

This audience may not exist in the Zope community-at-large. I don't presume that anyone here wants to help me address their needs. I was simply following up on what I thought was an offer of help, which turned out to be a simple hallucination.

That is the value in general. I, personally, have a more specific itch to scratch. I'm interested in what I call Plone-on-Demand, the ability to host Plone sites as a service. I want people who don't know Python or Zope or Plone, who simply want a website, to be able to go to a web page, fill in some options about what they would like in their website (skin, functionality, etc), and, 20 minutes later, get an email saying 'Here's the url of your new website - enjoy!'. This competes with similar services built on PHP at providers like godaddy. I want this for my university, which has a need for a web hosting solution and I think Python/Zope/Plone is appropriate. The buildout builder is a step in this direction. If I write the infrastructure for Plone-on-Demand, I intend to open-source it. It could be used by other service providers who currently shy away from Zope and Plone. It can also be used to provide demo sites for evaluation, perhaps deployed on a public grid.

If you still think this is the wrong route to follow, I'm interested in hearing your reasons. But, in my view, this is good for the Plone community in several ways. Coupled with the new TTW story unfolding in Plone 4.0, Plone-on-Demand could be quite powerful for users who never touch the filesystem directly.


Zope3-users mailing list

Reply via email to