[whups] Re:

[Chuck Hagenbuch]

Quoting Anil Madhavapeddy <anil@recoil.org>:

> For example, if one feature request requires a fundamental re-design
> of an API, that requires a great deal of communication with all the
> other developers to ensure that their own feature branches work without
> getting massively out of sync.  In open-source projects, this simply
> isn't feasible; in Horde's case for example, the changes are 'just made'
> and other features adapted to work with the new API.  Perhaps this is
> weak from a specification->rollout lifecycle point of view, but I
> doubt we have the resources to pull this off.

Yeah... speaking about Horde specifically, well, I'm not _too_ ashamed that the 
system was NOT well designed from the start. Horde grew out of IMP and 
realizing that we'd written some code for IMP that would be useful for other 
webapps. The whole thing has "grown" in a rather organic fashion from there. 
One of my main goals right now with the cvs branches is to get everything 
sorted out into a set of sane APIs, and to make those APIs as robust as 
possible, in order to make the whole thing more suitable for use in the long 
term. Unfortunately, it means breaking a lot of stuff as I go. =)

> I view Horde as being the 'glue' that provides the integration and
> possibility of interaction between these modules, via the registry
> and the other objects.  So what do people think about saving WHUPS
> for the ticket-tracking system, and moving the CVS viewer and 
> FAQ system to other modules?

I agree with you. To get to where I sort of envisioned this being, it's going 
to take a much better implementation of the Registry than we currently have, 
but that's okay; it needs to be done for other reasons as well.

Moving the FAQ system to another won't be a problem, as currently there's no 
faq system. =) Anil, if you decide on a name for the cvs viewer, I'll move the 
files in the repository so we don't lose any history...

> That is actually already on my TODO list, but my initial prototype
> placed a huge load on the web server when retrieving a given tag
> (since it had to iterate through the entire directory tree).  This
> _really_ depends on having a caching backend to make the queries
> a bit less painful.

Okay, let's talk about the caching backend: is the db schema that you mentioned 
earlier (from bonsai) going to handle this particular need? Is it absolutely 
reliant on having a database? Or could this be more general - either a general 
caching scheme, or a cvs caching scheme generalized over multiple backends?

But, really, I don't see any reason to try harder than necessary to avoid 
requiring a database for this. It might be nice if most things worked without 
any cache at all, but someone running a cvs repository is probably going to 
have a database available to them. So if generalizing it to more than "generic 
sql" is silly, forget it.

> Interest is good!  Please keep the ideas and input coming so we can
> kickstart this off!  As for how bugzilla, cvs and faq-o-matic will
> interact - I have no idea either!

Well, the things I had in mind were things like:

- when a user searches the faq, bug reports are also searched. This way people 
find out if a bug is open, or has already been fixed, with one search, instead 
of two.

- it should be easy to maintain a link to a revision of a file (ie, without 
hardcoding a full url - just the revision and filename), to be used for example 
in the bugs interface so that if you go to a closed bug, you get a link to the 
patch that fixed it.

... stuff like that.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"If you can't stand the heat, get out of the chicken!" - Baby Blues