On 10 July 2010 00:03, Johannes Raggam <[email protected]> wrote:
>>  - Three-level-nested namespaces are usually overkill.
> -1 (IMHO) ... i started to organize my projects like so:
> COMPANY.PROJECT.FUNCTIONALITY, e.g. MY.CUSTOMER.buildout,
> YOUR.CUSTOMER.layout, ...
> but for most collective packages, you're right.
> however, i don't like the java namespace convention like:
> org.eclipse.core.filesystem.linux.x86

You are German, I take it? :-)

Deeply nested namespaces are just extra sit-ups, and quite
un-Pythonic. Frankly, I think even plone.app.* is annoying. In this
case, doubly so.

>>  - collective.lib.* is completely non-describe. So much stuff can be
>> described as a "library" owned by the (Plone community) "collective".
>> This means the .lib bit is useless. What's going to happen (trust me)
>> is that people will start putting all kinds of stuff in there, and
>> then we'll just have a thousand packages with collective.lib in front
>> of them.
> the idea behind c.lib.* namespace is, that it should be for packages
> which integrate external libraries (non-python based software which are
> provided by browser-resources). they are meant to be used by other
> packages and cannot be used as plone-plug-n-play-products...
> maybe collective.ext.* would be a better name.

The collective is a very open space. There are dozens of packages
already that don't follow this convention, and dozens of packages that
will be created in c.lib that won't follow your definition. I just
wouldn't do it. Make short, descriptive names, and people are more
likely to find and tolerate your software.

>> Why not just improve collective.flowplayer?
> well,
> i guess i'll try that.
> it's well maintained and the features are rocking.
> and there is some room for improvements.
>
> although the event-based browser-view switch scares me a bit for the
> project i'm gonna need flowplayer. it's cool for a plug n play product,
> but i will at least z3c.unconfigure that feature.

Why don't you propose/implement an improvement to c.flowplayer that
make this configurable without z3c.unconfigure? That's the whole point
of the collective.* namespace - we all "own" it.

Martin
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers

Reply via email to