Malthe Borch wrote: > Perhaps packages which provide middleware functionality should be > named ``wsgi.*``, e.g. ``wsgi.bitblt`` or ``wsgi.who`` and we'd opt > similar namespaces for packages that belong to other realms.
I think it's better to use top-level namespaces to indicate ownership, if nothing else to avoid the chance of things clashing. For the repoze project to "claim" the wsgi.* namespace seems both a bit presumteuous and clash-prone. > I'm not sure this ``repoze.*`` notion is very healthy in terms of > getting traction outside the Zope-community, although .what and .who > have gained some popularity in spite of their nebulous namespace. You think so? First of all, repoze != zope, and secondly, I'd rather hope people had grown out of discarding code based on a name or a namespace. With all the reach-out work Chris and others have done, I'd be surprised if the repoze.* name was turning people off. If anything, it seems that people from "outside" equate "repoze" with repoze.who being used in TG2. :) > What's the feeling on brand-like names such as ``WebOb``, or > ``Routes``? That might be the right approach for more conceptual > packages. At least that's my motivation for naming the new package > ``Chameleon``. I think .who might fall in this category, not being > just a library, but something more conceptual, e.g. ``Who``. Plone people (and me personally) prefer to "own" a namespace. What if someone else had the idea to call something Chameleon, which is not entirely unlikely? What about a more generic name? Must we always come up with a suitably quirky name when a more functional one would do? Incidentally, I bloggedt about this stuff in the context of Plone yesterday: http://martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces/ Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
