[Kroupware] Questions about Shared Resources & Concurrent Access

[Diego Rivera]

On Mon, 2003-05-19 at 08:59, Bernhard Reiter wrote:
> > How is a scenario like this handled?  In cases like this automation (via
> > Sieve) might not be an option since human intervention might be
> > necessary before assigning a particular timeslot (i.e., is this
> > authorized by X, Y, are more than X people attending, do you require the
> > room because of its equipment?) - or even deciding whether to allow the
> > appointment request to proceed.
> 
> We've already thought of many scenarios and how to model them
> using the Kolab approach. Not all of the possible applications
> can be modelled with the current state of the software, though.
> 
> In this case the people who want to book a shared resource, like
> a conference room, just invite that user dedicated for that room.
> Let's assume that Kolab account for it is named room1.
> 
> At least on client has to work on "room1" to confirm the bookings.
> For the KDE Kolab client there is already button that makes it
> accept all invitations which are bookings in this particular case
> if there are no conflicts. If you switch that feature off, 
> somebody (e.g. a secretary) has to confirm this manually. 

Well...here's the thing:  room1 might not necessarily have a person
assigned to confirm bookings to it.

Assume two users: user A and user B trying to get a 1 hour, 1:00pm
meeting with resource X.

A and B both try to get the appointment at the same time, read the
existing appointments, realize 1:00pm is open, and book the
appointments.  Thus, 1:00pm is double-booked.  In the scenario I
describe, the correct behavior would be that one of them gets bounced
because the other beats them in the race.

However, this gets complicated to do (using anything short of a
dedicated calendaring server product) using file-transfer mechanisms. 
Mutex locking with file transfers run the risk of clients holding locks
through crashes, which is NOT correct behavior.

I don't think a dedicated calendar server is the answer so I definitely
will side with anyone who opposes using one (client compatibility issues
for starters).


I'll give this some thought, and post back later...are the scenarios you
mentioned described in detail somewhere?   I went through the
architecture docs and some are described, but not in a whole lot of
detail.  I'd like to see more (if there's more to see), and see if maybe
I'm barking at the wind...

Best

-- 
===========================================================
* Diego Rivera                                            *
*                                                         *
* "The Disease: Windows, the cure: Linux"                 *
*                                                         *
* E-mail: lrivera<AT>racsa<DOT>co<DOT>cr                  *
* Replace: <AT>='@', <DOT>='.'                            *
*                                                         *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu         *
===========================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030519/c75c1c81/attachment.bin