[dev] Horde 5 was: Re: [commits] Horde branch develop updated. fa956a4d83a7227e2a5d47bfe87185854e151fbc

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> When we discussed the new release model for Horde 4, one of the  
> important points was indeed that we don't want to fear breaking BC  
> if we consider it necessary to go forward. I say we have reached  
> this point, and instead of spending too much time in such  
> discussions and causing frustrations, we should make the next  
> release Horde 5.
> I already considered to bring this up before this thread started,  
> because if we really manage to get the new design in place for the  
> next release, this would probably be a large enough change for the  
> end users that it warrants and a new major version, even if we  
> didn't break BC.
>
> If everyone could agree to this, let's go forward with Horde 5 (and  
> let's quickly update any conference, paper, article applications  
> that mentioned 4.1).

Being the one who sort-of initiated this point, I probably should be  
saying +1 with an exclamation mark.  But just a couple of thoughts:

* The issue with me jumping major versions (despite Firefox/Chrome's  
attempt at a paradigm shift) is that it suggests there are going to be  
major changes to installation and config.  I don't believe that is  
going to be the case.  Most of the things that will be changing will  
be core-stuff; looking at 4.1 (or 5.0) as an end-user, you are really  
not going to notice a difference.

Maybe this is just an educational thing.  But I wonder if some users  
will be a bit hesitant to upgrade solely because they fear things are  
going to break.

* I would like to see a bit more clarification regarding what Horde 5  
means.  Because it is a bit confusing at the code level since it  
really is no longer horde (the application) that is important, it is  
Horde_Core (the package).  Not sure if we can, or should, do anything  
about that for purposes of keeping things simple for the customer.

But while it is fresh on my mind, and so that I have a record of it,  
thought I would lay down some elements on how to fix the whole  
Registry init mess that led to this thread.  The way I see it, we need  
the following:

init(): Given the fact that people have been using this method  
incorrectly, its probably best renamed to something like bootstrap().   
It's the minimum code necessary to allow the registry to access the  
application framework (NOT the application data).  E.g. setting up  
factories.  This method is potentially called before an application is  
authenticated, and possibly before the framework is available.

authenticateInit(): This is a method that is called ONCE per session,  
when an application is authenticated to.

init() (or onPush()?): This is a method that is called ONCE per page  
load, when the application is first pushed onto the stack.  This is  
where global application initialization can be done, although as a  
practical matter things should be auto-loaded as needed to reduce  
resources.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]