[Kolab-devel] Resource Management in Kolab 3.0

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-03-12 14:33, Jeroen van Meeuwen (Kolab Systems) wrote:
> As per http://wiki.kolab.org/Kolab_3.0_Resource_Management
>

Some additional questions came to mind;

- Where are (the calendars for) two identical resources (going to be) 
stored in IMAP?

   Do we think shared/resources/Cars/Car #1 and 
shared/resources/Cars/Car #2 for two cars that are exactly the same, the 
nested level "Cars" indicating they are two of the same perhaps? Would 
that scale up to:

     - shared/resources/Cars with Stickshift/
     - shared/resources/Cars with Powersteering/
     - (...)

   To be honest, I don't think so.

   Do we think shared/resources/Car #1 (and Car #2) calendars need to be 
annotated / contain a configuration XML object?

- How are we going to identify someone wants "that specific car" vs. 
just "a car"?

- How do we identify resources?

   Presumably, they are part of an LDAP address book, but use a 
different classification (so you can invite people to a meeting and 
(separately) select the resources you need for that meeting). Perhaps 
we're thinking of a new objectClass?

   Alternatively, the resources could be contained within objects in 
(specific) IMAP folders, though I am not sure;

     1) what the tree of IMAP folders would look like,
     2) how to administer the resources contained within such folder(s), 
or
     3) what that would do for delivery of invitations.

> I'm thinking about a way to implement this, but I need some
> clarification on what the flow is of messages.
>
> Suppose John reserves Car #1 for Monday and Wednesday.
>
> Suppose Jane reserves Car #2 for Monday and Tuesday.
>
> The reservations now look as follows:
>
>        | Monday | Tuesday | Wednesday
> -------+--------+---------+----------
> Car #1 | John   |         | John
> -------+--------+---------+----------
> Car #2 | Jane   | Jane    |
>
> Suppose Max wants to make a car reservation for Tuesday and 
> Wednesday.
>
> The following questions come to mind;
>
> - What is Jane's reservation?
>
>    - Is Jane's reservation based on needing the car Monday morning
> throughout Tuesday evening (do not return car Monday evening), or;
>    - Is Jane's reservation really a Monday, and also Tuesday (return 
> the
> car on Monday)?
>
> Suppose Jane does not return the car on Monday (and that in fact was
> the plan as well);
>
> - What is displayed to Max wanting to make a Tuesday-Wednesday
> reservation?
>
>    - Does Max see a "just try to make a reservation we'll attempt to
> figure it out and let you know"?
>    - Does the client (responsible for rendering the UI that Max is
> presented with) offer a car available or not available, or
> tentative/maybe?
>
> Furthermore;
>
> - Is the client responsible for the capability to render the
> availability information, or is the client offered with such
> capabilities?
>
> Also;
>
> - The most effective way to negate the entire problem is to 
> immediately
> re-schedule John's reservation on Monday (for Car #1) to Car #2, and
> Jane's reservation (Car #2) to Car #1, freeing up Car #2 for Tuesday 
> and
> Wednesday - however, given that cars are written off over a period of
> time and mileage, it's probably not sustainable to put load on any
> particular one of the resources in the set, and this re-scheduling 
> would
> need to be balanced somehow. This would greatly complicate the 
> resource
> management - but could be implemented.
>
> Kind regards,
>
> Jeroen van Meeuwen

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08