> - 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
> - 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. > 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. ...hannes _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
