[dev] [commits] Horde-Hatchery branch master updated. 32b8d7d18cb8987b1235005df6567d4d37e87950

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>>> My suggestion is more along the lines of: for each system task  
>>>> that needs to happen once per user, store the revision number of  
>>>> the system tasks in their preferences (instead of storing class  
>>>> names). So we start at revision 1. Each change gets a new  
>>>> revision number (changes made together get the same revision  
>>>> number). We update prefs.php.dist so that the default value is  
>>>> always current (or we could have a special call that returns the  
>>>> current level).
>>>>
>>>> Then on login, we get the user's current level, see if there are  
>>>> any tasks after that, and run them.
>>>
>>> This seems like it is adding too much complexity in the  
>>> logintasks.  Additionally, this requires us to load/parse the  
>>> SystemTask every time a user logs in.  The present method doesn't  
>>> require this.
>>>
>>> I still think that a command-line script is the preferred solution  
>>> (it is written and currently lives in  
>>> horde-support/maintainer-tools).  Upgrades are not all that  
>>> common, and not that many people are running dev code, so this  
>>> seems more appropriate.  And on the plus side: upgrading still  
>>> becomes much easier because of having to find/run the appropriate  
>>> script, we only need to do:
>>>
>>> cd [hordebase]
>>> php horde-run-task.php -a [app] -t [taskname] -u [username]
>>>
>>> anytime an upgrade is announced.
>>
>> I don't think upgrades are as uncommon as you think, if you take  
>> all applications into account. And maybe more people would run dev  
>> code (and get into helping development) if we made it easier.  
>> Keeping accounts/prefs/data up to date is one way to do this.
>
> I still personally think that the whole 'incremental' counting is  
> much kludgier than running command line scripts.  And again - it  
> adds a whole bunch of overhead to every user's login whether they  
> use developmental code or not.  I am not a big fan of requiring  
> 99.9% of users to run code that will *never* be needed just for the  
> .1% of users that may need it.
>
>> A command line script just feels kludgy to me. A general solution  
>> that works for developers and end users regardless seems much more  
>> elegant to me and worth it in the long run.
>
> But we've been doing things command-line for years.  LoginTasks were  
> not designed to fully replace upgrade tasks.

Okay - any other opinions here? If no one else feels strongly about  
the side I've been proposing, I'll agree to go with command line  
scripts for now.

-chuck