reinhold at kainhofer.com
Wed Oct 6 16:05:30 CEST 2004
On Wednesday 06 October 2004 15:34, Bernhard Reiter wrote:
> 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,
Yes, the time zone issue is a general KOrg problem, not only for groupware.
> the identify problems
Which identify problems?
> and the difficulties with inviting and directly
> writing calendars.)
Which problems are these?
> > > 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 reference to a local file system is something that I believe is not
> good and should be avoided in all groupware systems.
So how do you want to handle them? Always attaching the whole file to the
event. Now, add a few images, and you'll end up with a >10MB calendar...
Also remember, KOrganizer is not a synonym for "Groupware system". Some people
also use korganizer as their "project" management system, where they put the
references to all the documents needed into the events' attachments, to have
easy access to them.
> > 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.
So what? All information needs to be preserved, anyway.
Basically, you are saying, that korganizer mustn't support more than any other
calendaring application does support?
Just because Outlook and Evolution don't support hierarchical to-do lists,
that doesn't mean korganizer can't support them. The rfc give a standard for
this, and if one application does not support relations, okay, fine, but
others can make use of it.
> > 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.
> 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.
What's a 3rd system and a 2nd system?
iCalendar also specifies that unknown tags MUST be preserved (emphasis copied
from the rfc).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the format