bernhard at intevation.de
Wed Oct 6 15:34:28 CEST 2004
On Wednesday 22 September 2004 16:37, Reinhold Kainhofer wrote:
> On Wednesday, 22. September 2004 16:08, Bernhard Reiter wrote:
> > On Wednesday 22 September 2004 13:50, Reinhold Kainhofer wrote:
> > 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.
I tend to disagree, because it cannot be used in a groupware
setup with several people. (This is not a topic for kolab-format,
I am thinking unique id problems, the time zone issue,
the identify problems and the difficulties with inviting and directly
> > 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
As I wrote above: I tend to disagree,
but this is certainly a matter of perspective.
For some users a gropware funcationality with remote resources
is not that important, for others it is crucial.
> 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?
No, I hope that we can make that configurable if we do not agree
that it might be too much funcationality.
(Because in some cases too many features are a step back.
for the usability)
> > 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
The reference to a local file system is something that I believe is not
good and should be avoided in all groupware systems.
(Thus I would suggest to not add support in the format for it.)
As for URL references and attachements to events and todos:
I was talking about them, because
in the Kolab2 XML storage format those are email attachments
(which get referenced in the XML).
> 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.
This is a drawback, because you can never be sure if
the other client can do what you can do.
> 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
That is not completely true as we preserve unknown tags.
In general I believe the approach is excately what is needed
from a 3rd system and iCalendar feels like a typical 2nd system format.
> > > 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.
I am not to set your priorities, but as written above I believe that you
are fostering a small user base instead of a bigger one.
To reach corporate users multiple alarms are not
the stumbling block today.
> > > 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.
I never used sound here, for me that is a sign that this is not
that required in a even fancier version.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2145 bytes
More information about the format