[Kolab-devel] Which Korganizer features are important for Groupware?(was: Alarm setting?)

[Bernhard Reiter]

[Can we take this to kolab-devel?
Reply-to set. (KMail cannot easily set Mailfollow-up.)]

On Wednesday 06 October 2004 16:05, Reinhold Kainhofer wrote:
> 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?

Bo and David will have the details.
The problem is when you act as a secretary for somebody else
and have write access to several groupware calendar folders.

> > and the difficulties with inviting and directly
> > writing calendars.)
>
> Which problems are these?

Details are also in the tracker, e.g. you cannot load two UIDs,
which appears when you have access to the calendar folder
of your friend which you just invited by email.

> > > > 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...

For now I want to do this and thinking about real document management
systems in a distributed world with several servers is a hard problem.
Someone could think of URIs or so.

> 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.

This is just what I am saying: KOrganizer is not ready to be part of
a real "Groupware solution" and in making it ready we also think
of what it should be and how it can be that.

> > > 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.

But not presented and dealt with. 
In saying this is the information you need to deal with at least
to be compatible, we actually allow a practical Groupware storage
format for the first time.

> 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.

No you seem to missunderstand me here.
I have no problem with KOrganizer begin able to do anything,
but I also want Korganizer to be part of a practical groupware solution.
We need to approach this state somehow and yes for this to do
we need to take two clients and try to find a common set 
of groupware funcationality that users already know
and then start with that as a practical approach.

> > > 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?

http://en.wikipedia.org/wiki/Second-system_effect

Best,
    Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20041007/6d14b3b8/attachment.p7s>