Kronolith idea

Kronolith has the posibility to show tasks in the calendar. I see, it has even 
an inactive birthday display code. But there are other applications that have 
time associated data (whups, hermes etc). 

Why not introduce an general api call listTimeObjects (like listCostObjects 
is) common to all modules? So Kronolith will query all modules that can 
provide timed data. Or trick the user pref configuration to offer the user to 
select which type of data to display from the available.

Duck

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: Kronolith idea

Zitat von Duck <duck <at> obala.net>:

> Kronolith has the posibility to show tasks in the calendar. I see,   
> it has even
> an inactive birthday display code. But there are other applications that have
> time associated data (whups, hermes etc).
>
> Why not introduce an general api call listTimeObjects (like listCostObjects
> is) common to all modules? So Kronolith will query all modules that can
> provide timed data. Or trick the user pref configuration to offer the user to
> select which type of data to display from the available.

Very nice idea. And yes, this should be a user preference.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: [cvs] commit: horde/scripts/sql create.mysql.sql

Zitat von Matt Selsky <selsky <at> columbia.edu>:

> selsky      2006-06-30 13:51:39 PDT
>
>   Modified files:
>     scripts/sql          create.mysql.sql
>   Log:
>   These indexes are not actually used in MySQL.  The query analyzer   
> always chooses the primary key index for the queries that we do.

Not when I ran the analyzer. Besides the SELECT 1 query, all SELECT  
queries used the new indexes. It might depend on the data structure,  
we should keep it in because it doesn't hurt as much as it might gain  
some extra performance.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: [cvs] commit: ansel/lib api.php

Zitat von Michael Rubinsky <mike <at> theupstairsroom.com>:

> mrubinsk    2006-07-01 21:31:06 PDT
>
>   Modified files:
>     lib                  api.php
>   Log:
>   Add _ansel_getGalleryId() method to api for retrieving the   
> datatree_id when all we know is the gallery's name.
>   Any objections to this?

Without looking at the code, it might make more sense for an external  
API to hide internal IDs, OTOH we don't follow that paradigm in other  
APIs either. But the API for an application should at least be  
consistent, I guess.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: Kronolith idea

On Sunday 02 July 2006 13:52, Jan Schneider wrote:
> Very nice idea. And yes, this should be a user preference.

I prepared a working patch for kronolith/nag transformation. Of course is 
still not connected to kronolith's prefs and all the kronolith templates 
should be patched to support different id since now tasks are hardcoded.

Duck

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: Kronolith idea

Done.

Kronolith now shows and links events not only from nag but from all apis with 
listTimeObjects defined in users prefs.

Is very useful. For example I wrote an application to be used with Minerva. Is 
a tracked for incoming invoices. Now our finance people can see when some 
bill must be paid directly in their calendar in Thunderbird.

Duck

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

kolab smtp server settings

Hi,

for what are the "Kolab SMTP Server Settings" being used which i find
in the "Kolab Groupware Server"-tab?
(Administration->Setup->Horde->Kolab Groupware Server"). I think they're
more or less useless.

linux:/srv/www/htdocs/horde # grep -ri -P "\[\'kolab\'\]\[\'smtp\'\]" *
config/conf.php:$conf['kolab']['smtp']['server'] = 'localhost';
config/conf.php:$conf['kolab']['smtp']['port'] = 25;
config/conf.php.bak:$conf['kolab']['smtp']['server'] = 'localhost';
config/conf.php.bak:$conf['kolab']['smtp']['port'] = 25;
linux:/srv/www/htdocs/horde #

It's nowhere used.

Is it possible to remove this from the conf.xml? (i attached a patch)

Marcus

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: [cvs] commit: ansel/lib api.php

Quoting Jan Schneider <jan <at> horde.org>:

> Without looking at the code, it might make more sense for an external
> API to hide internal IDs, OTOH we don't follow that paradigm in other
> APIs either. But the API for an application should at least be
> consistent, I guess.

I agree about hiding the datatree_id from external apps, and was how I  
was actually expecting the api to operate...but just about every one  
of the methods that needs information about a gallery expects the  
datatree_id.

Since ansel has not been released yet, would it be feasable to rewrite  
the api to expect the more appropriate share name?  It's how I would  
have preferred to do this, but was concerned about making such a large  
change to the api...

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk <at> horde.org

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: [cvs] commit: ansel/lib api.php

> I agree about hiding the datatree_id from external apps, and was how I
> was actually expecting the api to operate...but just about every one
> of the methods that needs information about a gallery expects the
> datatree_id.

This is because using datatree_id is *much* faster than using datatree_name.

> Since ansel has not been released yet, would it be feasible to rewrite
> the api to expect the more appropriate share name?  It's how I would
> have preferred to do this, but was concerned about making such a large
> change to the api...

Ansel hasn't been released yet, but other apps that use ansel have,  
such as IMP.  That, plus the performance benefits of using the  
dataree_id lead me to say that we should not change to share names.   
If anything, we should ensure that we are using datatree_id in all  
function calls for consistency.

--Ben

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org

Re: [cvs] commit: ansel/lib api.php

Quoting Ben Chavet <ben <at> horde.org>:

> Ansel hasn't been released yet, but other apps that use ansel have,
> such as IMP. That, plus the performance benefits of using the
> dataree_id lead me to say that we should not change to share names.
> If anything, we should ensure that we are using datatree_id in all
> function calls for consistency

Sounds good to me.  I'll leave in the getGalleryId method then, for  
those external apps that may only have the gallery name available.  I  
also already made some minor changes to make it more obvious when we  
are talking about ids vs names.  I'll take a look at the rest of the  
api shortly and see if any other changes should be made...

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk <at> horde.org

--

-- 
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe <at> lists.horde.org