Re: Re: Templates in PEAR

David Costa wrote:

On Jun 2, 2004, at 7:34 PM, Michael Wallner wrote:

Hi David Costa, you wrote:

right and remove the others ? very good idea...

David, that's not the point. :) Just wanna be a lead is the wrong intention. I'm talking of the compound force of TPL devs to create highly versatile and modular template engine, allowing multiple approaches or whatever...

it is surely a good idea but as far as I know the current packages have some differences and they all have downloads. This leads me to believe that they have their own niche.

If each current lead of the template engines that currently exists in pear are joining a team, nobody will be left out, if that is your fear.

I have no fear ;) but I would see why a lead wouldn't want to merge his package with another one in the templates area. I think that templates are very different then, let's say, math or networking packages. Whilst the latest categories are mainly providing with a functionality (and the user at times doesn't really care as much) template engines are a category apart. If adopted the end user will spend a great deal of time with them. For instance, if I am using template Sigma or I used it for.. let's say 10 websites. It would take a major effort to adapt the sites using the "new" template we are talking about. Of course I could leave the site with the old, deprecated engine but.. Of course you can say that the old packages will not disappear, but still it wouldn't leave a good image of PEAR. Of course I am all for removing dead/zombie packages. But on templates, I don't see a case at the moment. I might be wrong, but this sounds mainly a lead to lead business. If they want to merge, fine, but we can't impose anything on this direction.

I absolutely agree with this. Templates are their own category, and cannot be treated as something that can be combined. What always happens when you combine things like this is that you end up satisfying no one (except, perhaps, the participating developers). In your requirements for your application, you probably will tell the customer exactly what needs to be installed. By installing only the necessary components, there's a lot less risk of having customers who think they can do it themselves mess everything up when they edit the configuration file when moving to a new provider. Of course, you could always hard-code it... And besides, since when do we want to be like Microsoft, including a vast number of things that no one will ever use? Should users consider PEAR bloatware? As soon as we have sub-packages, we could consider it. And it's nice if you get special templates and are able to use using an API you are used to. That's the only benefit I see of a unified template package. I also agree fully with David on retroactivity of rules. As you probably know, you cannot be convicted for something you committed if a law making it illegal was passed _after_ you did what you did. It's a very important legal concept. And it prevents lots and lots of problems. Let's not start overturning it here. Klaus