Alarm setting?

[Reinhold Kainhofer]

On Wednesday,  22. September 2004 16:08, Bernhard Reiter wrote:
> On Wednesday 22 September 2004 13:50, Reinhold Kainhofer wrote:
> > No, I don't think a simple reminder is poor.
>
> Then I might have missunderstood what you have meant eaarlier by:
>     I just read the kolab spec once again,
>     and it seems that the alarm settings  are very poor
>     in the current version in cvs.

I meant "poor in the amount of functionality that is provided for alarms", 
i.e. "poor" as in "only one possible setting is allowed" (although it's the 
most common, sometimes you'd like to have more).

> > In fact, it's the most common
> > way of alarms that users might want and use. But in some cases you want
> > multiple reminders for an event.
>
> Our idea with the Kolab2 format is to first support
> the most common way, 

Okay, I just wanted to tell you about my plans for korganizer. KOrganizer is 
already at the second step: It already has all the functionality for the most 
common way of calendaring. 

> because then the software (integrating 
> Kontact) can do something that was not possible before:
> Build a usable groupware solution.
> Within this the current choice seems fine for now.
> If that step is reached it makes sense to talk about the rare cases.

Okay, but I just want you to be aware that korganizer is progressing beyond 
its current capabilities.

> Do not get me wrong at this: I am in favour of trying to add more
> capabilites, but in terms of avaiable Free Software groupware solutions,
> it seems to be the second step before the first.

Okay. In terms of available Free Software calendar user agents, we are at the 
second step, and now I'm thinking about more capabilities for korganizer.

> > procedures are actually quite helpful. E.g. before an important meeting
> > you can automatically run a script that extracts some statistics about
> > the current status, etc.
>
> Some of your examples are interesting, still they look like second step
> to me and like not considering the possibilities when saving this in group
> folders on a server and with access of different groups of people.

So your suggestion is to just remove all functionality that might not work 
with a shared folder? or with different groups of people accessing it?

> > Nope, not reliably. But it's the same issue with attachments, too.
>
> I do not see a problem making attachments like email attachements
> to work reliably cross plattform. They are just binary blobs with a
> content-type.

I'm not talking about email attachments. I'm talking about attachments to 
events and todos. You can attach any URI (e.g. path to a local file, a URL to 
some web page, or a link to a mail in kmail) to incidences in KOrganizer. Of 
course, the local pathes and kmail uids will be highly platform-dependent.

> > > The RFC even openly admits the security problem of an attached
> > > application, which smells like bad design.
> >
> > The scope of the RFC is not to make a specification that is absolutely
> > fireproof, but rather it aims to give a specification for all possible
> > things that one might like to do with a calendar. And for this, procedure
> > alarms are an important thing. Of course, the RFC has to point out to the
> > developers that they should think very thoroughly about how to implement
> > procedure alarms without introducing security problems.
>
> This is one of the problems I do see with this RFC, it does not consider
> the importance of the use cases. Because common and rare (and less
> important) use cases are treated equally it is very hard to implement a
> fully compliant software.

The RFC is not meant as a guidline what a calendaring app MUST implement, but 
rather tries to be a complete specification of all the things a calendaring 
app MIGHT ever want to implement. 

Your Kolab specification is just the other way round: It defines the things 
that a kolab client MUST implement, which is only the most common features. 
If an application supports additional features, well, it's basically on its 
own.

> > These issues ARE demanded by the users:
> > Multiple alarms: bug #16493 (one of our oldest wishes)
> > email reminder: bug #50292
> > reminders relative to the end: bug #82105
>
> I read through the issues now.
> My estimation still holds that this is not the most important thing
> and other stuff is more important, especially in a real groupware setup.

For kolab2 that might be true. 
For KOrganizer as a calendar user agent, these are my priorities.

> > And in case you didn't notice: Sounds and procedure alarm have already
> > been supported by korganizer for some years...
>
> I saw that, but I never used it.
> How many different alarm sound do you have set?

I don't have any, but then I don't use alarms at all, anyway.

Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20040922/05685ca7/attachment.sig>