[Kroupware] Re: Questions about Shared Resources & Concurrent Access

[Bo Thorsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 19 May 2003 22:10, Diego Rivera wrote:
> On Mon, 2003-05-19 at 14:45, Martin Konold wrote:
> > Am Montag, 19. Mai 2003 18:25 schrieb Diego Rivera:
> >
> > Hi,
> >
> > > 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.
> >
> > Well, basically the user trying to book a ressource has to wait for
> > the confirmation. The kde kolab client only sends a single
> > confirmation on a first come first serve race in case you chose the
> > automatic mode.
>
> That's exactly my point : while the Kroupware client might have
> mechanisms for doing this - what IF they're not using Kroupware?  Say -
> Outlook over FTP?  That will be a common scenario and I don't see any
> true way to keep this from happening.

The automatic resource handling must be done with a kmail running. That 
you might have some other common scenario is irrelevant. I would actually 
also prefer to have this done on the server or by a special application, 
but that's not the way we did it.

Bo.

- -- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+ycugmT99lwfUS5IRAnzLAKCBrB4y+G8GO9HdQIbCD0e/BYvCjwCfcjl4
kmktuE9XiqlKkjMGpJAiq3A=
=eN25
-----END PGP SIGNATURE-----