[development] Taxonomy2

[Jeff Eaton]

> If we are ever to replace the book and taxonomy modules in core with
> something more powerful, then there absolutely MUST be an upgrade
path.
> If a new relationships API isn't able to achieve that, then it's
simply
> not practical. Sorry to sound so negative about it, but building such
> an upgrade path is a task for which I personally don't see the light
> at the end of the tunnel.


Whenever there is talk of something as fundamental as changing Taxonomy,
the benefits need to be overwhelming to justify the changes.
Category.module's solution is good *given the presupposition that
Taxonomy as it exists will remain in core*. It's remarkable in that it
requires no core patches -- a testament to both the clean design of core
at the moment and your skills in writing and maintaining the wrapper.

The suggestion at the beginning of this thread, however, was that
Taxonomy itself be revisited and rebuilt with greater flexibility. I
agree wholeheartedly that an upgrade path is an absolute must. If we're
talking about a rewrite, though, all we need to do is provide an upgrade
*path* -- not a mirror of the current module's data structures. Dman's
relationships module, for example, is a conceptual superset of both book
and taxonomy. The data for both modules can be expressed in
relationship.module, and taxonomy/book wrapper functions could in theory
be provided to expose those relationship types in backward-compatible
ways. I'm not suggesting it as an 'alternative' to taxonomy, just an
example of the sort of next-generation system that would add more value.

To summarize, I think that providing an underlying API for general
relationships -- which taxonomy and book would both be upgraded to
utilize -- would provide more long-term benefits for Drupal than
layering more and more functionality (and compatability wrappers) on top
of what is essentially the same system.

Yes, it takes work. Yes, it would be a difficult conversion. No, it is
not impossible -- no more than formsapi was. That was a pain and a half
(still is in some ways) but it is a similar leap in terms of core
flexibility and functionality. In this case, we also have the advantage
that most modules don't concern themselves directly with taxonomy --
taxonomy.module does the heavy lifting via nodeapi.

--Jeff