-------- Original Message --------
Subject: Re: Moving towards 1.1 - Migrating Plugins
Date: Tue, 8 Jan 2008 00:57:19 -0800 (PST)
From: Simone Carletti <[EMAIL PROTECTED]>
To: Fabien POTENCIER <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
As a ZF contributor I really agree with this proposal and this is
something I suggested long time ago
http://groups.google.com/group/symfony-devs/browse_thread/thread/3a90d937bda25e33/346e921ebb8f4660?lnk=gst&q=plugins+weppos#346e921ebb8f4660
> Even though I think at the Zend Framework,
> they take the whole specification and acceptance to a level that is
> too hard for people to contribute, the way you describe it here makes
> it much better.
I do not totally agree.
It's true, at ZF there's a wide use of high level PHP constructs and
professional development practices (such as deep unit testing) but I
don't think Symfony should start will a lower expectation.
I mean... I think a lower number of high quality and long time plugins
is better than an high number of feature less or discontinued ones
such as WordPress or PEAR.
I think the Core team, supported by the community, should find/define
a reasonable high quality standard as a starting point. There's always
time to adjust it.
-- Simone
On Jan 8, 7:29 am, Fabien POTENCIER <[EMAIL PROTECTED]
project.com> wrote:
> What if someone becomes a core team member? All its plugins will have to
> be renamed?
>
> I think we ask the wrong question. I think the problem is not about
> prefixes at all. It's about:
>
> - usefulness
> - opensourceness (?)
> - quality
> - documentation
> - commitment (to maintain and evolve the plugin)
> - tests
>
> And those things are not related to a prefix or a tool like symfony-forge.
>
> Perhaps we can borrow some ideas from the Z..d framework:
>
> - We create 2 repositories:
> - 1 "offical" (/plugins)
> - 1 "incubator"/"experimental" (/plugins/experimental)
>
> - To install an "experimental" plugin, there is a switch on the CLI task
>
> - To be part of the official repository, you need to be "accepted" by
> the community based on some criteria described above (to be determined).
> This decision is not made by the core team, it's really a community
> decision. Perhaps we can have a plugin comity that ensure some
> fundamental criteria.
>
> - To be part of the "experimental" repository, you need to write some
> kind of a "light" specification and then be approved (the process here
> must be very light and fast as we want to encourage people writing
> plugins but as Dustin said we don't want n Facebook plugins or plugins
> that just wrap a library without any added value).
>
> If a plugin is not accepted in the symfony repository (experimental or
> official), you can still host it somewhere else. After all, it's just
> about hosting a PEAR channel.
>
> Fabien
>
> --
> Fabien Potencier
> Sensio CEO - symfony lead
> developerhttp://www.sensiolabs.com/http://www.symfony-project.com/
> Sensio Labs
> Tél: +33 1 40 99 80 80
>
> Tristan Rivoallan wrote:
>
> > On Jan 7, 2008 11:21 AM, Ian P. Christian <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
>
> > Tristan Rivoallan wrote:
>
> > > yes, but i'm afraid we still need a namespace for each plugin. For
> > > instance, most of my plugin have their own "inflector" class. How
> > can i
> > > distinguish them if we only have one "usf" namespace ?
>
> > The prefix has nothing to do with this - if you were to use 'tr' as your
> > prefix, you'd still have this problem.
>
> > indeed, that's why i think there's a need for one namespace for *each*
> > plugin.
>
> > What yuo might however want to
> > do is create a 'trToolkit' project and put shared things there.
>
> > i do this when there are sufficient needs, but most of the time code is
> > really specific to plugin's needs.
>
> > If 'tr' became 'usf' then it doesn't really change anything at all.
> > Your class names should probably be usfPluginNameInflector
>
> > definitely, that's why i usually use plugin name initials as a plugin
> > prefix. Using the full plugin name is impractical when your plugin is
> > name is too long, eg. :
>
> > * usfPropelActAsNestedSetBehaviorInflector : yuck !
>
> > actually i think there are two problems :
> > * clear and attractive plugin naming, where the sf / usf distinction
> > make full sense)
> > * namespacing to avoid conflicts between plugins, and where the sf /
> > usf distinction is not enough.
>
> > ++
> > tristan
>
> > --
> > Tristan Rivoallan
> >http://www.clever-age.com
> > Clever Age - conseil en architecture technique
> > GSM: +33 6 219 219 33 Tél: +33 1 53 34 66 10
--
Fabien Potencier
Sensio CEO - symfony lead developer
http://www.sensiolabs.com/
http://www.symfony-project.com/
Sensio Labs
Tél: +33 1 40 99 80 80
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
