On 12/6/05, David K Norman <deekayen@deekayen.net> wrote:

Ok, so I'm a little slow since I loaded the PHP|tek conference site and saw a Bryght sponsor banner. I guess since there already seems to be some stuff in the works, I'll just declare my strong interest in being involved.

Heh. For some reason I just got intrigued by their media sponsor program...basically if you have a site with page rank of 4 or more, you get listed as a media sponsor. I've stuck it on our calendar and James will likely submit a paper, but that's as far as we're going at this point. By all means organize a local get-together in that corner of the world. Next meetup is Vancouver in February, and ??? after that. David K Norman wrote:

...

The PHP|tek conference in Orlando, FL is going to be 4 miles (~6.4 km) from my house, so naturally I'm not only interested in attending, but bringing some Drupal representation in a presentation. Anyone interested in arranging anything?

Conference link: http://www.phparch.com/tek/

Call for papers deadline is Dec 21st.

-- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann

On 07 Dec 2005, at 11:09, Robert Douglass wrote:

Someone has been very very busy:

http://drupal.org/node/40233

The comment module uses a similar technique. As discussed before, the better approach would be to add a generic nested tree algorithm to core. Such algorithm could be re-used by the (i) comment module, (ii) book outlines, (iii) taxomomy trees, etc. I wish merlinofchaos would turn this into a generic core API, rather than a contributed module. -- Dries Buytaert :: http://www.buytaert.net/

Earl Miles wrote:

...

The comment module uses a similar technique. As discussed before, the better approach would be to add a generic nested tree algorithm to core. Such algorithm could be re-used by the (i) comment module, (ii) book outlines, (iii) taxomomy trees, etc. I wish merlinofchaos would turn this into a generic core API, rather than a contributed module.

Interestingly, I initially submitted this as a patch to core and was immediately told it didn't belong there.

I can think about how to genericize the algorithm and make it available to core somewhere. I'll have to look at the content module.

To elaborate a bit -- one of the reasons for core difficulty is that it simply doesn't work with multiple inheritance. My own answer to that, of course, is "Feh on multiple inheritance", and to just let it go. But it is an issue. And I typed content when I meant comment.

Karoly Negyesi wrote:

...

Interestingly, I initially submitted this as a patch to core and was immediately told it didn't belong there.

Well, killes commented in the issue that you will have problems with multiple inheritance. I just pointed out that with hook_taxonomy you could move this to a module. I was not thinking on other trees, but Dries is quite right that there are many single inheritance trees in Drupal (we talked a lot about them) AND many taxonomies are not multi inheritance -- they could benefit from this, too.

I hope this clarifies what's happened so far.

I think it was the right path, too. What Dries wants out of this -- and I had not even thought about -- is a generic algorithm that can be used for any tree. It makes a lot of sense, but I was only focused on taxonomy because of what I was doing. A little bit of contemplation is showing me that some thought is going to have to go into the design. I will post a draft on the forum later today for feedback. There's a couple of different ways to do this and I want to present them both (or all if I think of a third) and see what people think.

Adrian Rossouw wrote:

On 07 Dec 2005, at 6:36 PM, Earl Miles wrote:

...

A little bit of contemplation is showing me that some thought is going to have to go into the design. I will post a draft on the forum later today for feedback. There's a couple of different ways to do this and I want to present them both (or all if I think of a third) and see what people think.

Please also confer with Vlado about his work on relationships, as I think this ties into that.

Perhaps a little. We've chatted a bit about queries and Views. His plan is very, very generic, like Views, and both are very complicated. This is actually a very specific topic. Still, I will ping him next time I see hiim and get his thoughts.

Thanks Earl. I hope it is possible to come up with a generic implementation that is elegant; it could significantly speed up the book module.

I should note that the book.module actually supports a multiple-parent model. It is just the UI that prohibits it. See http://drupal.org/node/5901. I'd like to see us truly support this, instead of falling back to single parent model.

Earl Miles wrote:

Dries Buytaert wrote:

...

Thanks Earl. I hope it is possible to come up with a generic implementation that is elegant; it could significantly speed up the book module.

Looking forward to your designs,

http://drupal.org/node/40313

I've gotten, surprisingly, no comments on this at all. Has anyone looked at this? I need some feedback before I can move forward. I at least need to know I'm on the right track.

Adrian Rossouw wrote:

On 09 Dec 2005, at 3:22 AM, Earl Miles wrote:

...

I've gotten, surprisingly, no comments on this at all. Has anyone looked at this? I need some feedback before I can move forward. I at least need to know I'm on the right track.

My personal opinion is that a generic tree algorithm is less useful than the generic relationship API that has been proposed and is being worked on. There are four 'competing' implementations of this API, of which one (ally's hier module) is actually implemented as a nested tree in the database (iirc). Your implementation could almost be considered the 5th, albeit lacking in flexibility.

Trees / Hierarchies are just one type of relationship, and I also think that caching / persisting trees is probably going to be more effective for a lot of cases, but it will fall apart with _lots_ of data. I am not casting judgement on your code / plans, but I like how Vlado is approaching the problem, and thus my support goes to him.

I don't know that the two ideas are really the same. Everyone I've spoken with about the relationships are very interested in creating user-defined relationships and are focusing on a very generic setup. I think that's great, and I really look forward to seeing what they produce. That said, all of those implementations seem to be relatively far out. And I don't know that they'll actually address the problem this is solving. In fact, as a generic API, all of those relationship modules can choose, if they like, to utilize this API to improve the sorting results of their relationships, if they believe they will gain a benefit from it. You might say that my implementation is a relationship module that's lacking flexibility, but I disagree. It isn't defining, controlling, or even storing relationships. That's some other piece of code's job. This one is simply a piece of code whose sole purpose is to enhance the performance of existing code.

Robert Douglass wrote:

Someone has been very very busy:

http://drupal.org/node/40233

It turned out to be necessary to get Views to do something I thought it would be able to do much more easily =)