[horde] reagent: the code

Carlos Pedrinaci cpedrinaci at yahoo.es
Mon Apr 26 15:07:10 PDT 2004


On Mon, 2004-04-26 at 16:22, Mij wrote:
> well, I don't think that's a good thing to build such a "fat" module. 
> Beside the
> problems which come introducing more and more "areas" to a project, 
> it's one
> of Horde's very main goals to provide a framework for a set of modules 
> to carry
> out different tasks. Extending thor wherever just to merge developers 
> under
> one name doesn't gives me the idea the app has been critically planned 
> with
> an eye to its environment.
> What you think could as a "yep we would also include this in the 
> future" is not
> such a little thing. Of course if you just think to it as "yes, show 
> some user details
> and some project details" it can be reduce to something thin, but 
> that's far from
> what what i planned for reagent.

Basically, the point of Horde is that it provides a bunch of useful
utilities that help developers on the process of creating a particular
application. Moreover, there are mechanisms defined in order to allow a
better integration between different applications. As a result, creating
a complex application is strongly simplified.
You are extremely dared saying that I haven't planned Thor with an eye
in the environment. If you had checked out at least part of Thor's code,
you would have noticed that I do keep an eye in the environment (this is
certainly not the case for reagent which creates groups of users when
Horde has a very nice utility called Group which does exactly that, and
adds the capability to couple that with Permissions for example..).

> You should plan a bit slowly what wants your app to do. If thor is what
> you said, it is a tool to support specifically users and projects in 
> their
> self activity, not the community as an entity in a whole.

I thought the "community" was handled/supported by Horde itself.

> Its target is completely different: adding features is ok, add targets
> implies very easily less usability, far higher complexity, more 
> inclination
> to bugs, less security etc.


Again, check out Thor's code please. You will then notice that it does
allow sharing tasks among Project developers without complicating it at
all, because it uses Nag.

> 
> 
> > But imo all these things should just be "links" to the other pieces of
> > software available for Horde:
> 
> indeed

How comes that you are not using Turba for defining users information
then?

> 
> 
> > Well... I also started Thor on Horde 2 then moved to Horde 3.. now I'm
> > happy I did that.
> > It is true that institutions are usually reluctant to updating, that is
> > why Horde guys do a lot of work to solve compatibilities and migration
> > problems.
> > Obviously I can't prevent you from continuing to code based on Horde 2,
> > but in my opinion this is a mistake. If you go along with Horde, your
> > code will evolve together with it and your work will remain there. If
> > you do the work on your side, code will soon be obselete and you will
> > have a lot of work that is no more usable.
> > That would be a real pitty, don't you think so?
> 
> horde3 is still quite buggy.

I must disagree on that one. It does certainly have bugs as every piece
of software, but it is working very well. Check it out, sure you will
enjoy it.

> 
> I can provide to you (other people, if there's someone else interested)
> a login for a reagent demo. Please do the same with thor, so we can
> evaluate (somewhere away from this ml, better) which points can we
> make collide, what can we merge, what can we share etc.
> 

Give me some time and I will get you one account.

Carlos




More information about the horde mailing list