[dev] Kronolith resources

[Gunnar Wrobel]

Hi Micheal,

thanks for pushing your branch.

Quoting Michael Rubinsky <mrubinsk at horde.org>:

[snip]

>
> Gunnar, could you take a look too and see what would be needed to  
> make integrating this into kolab more likely?

I did take a short look and I will take a more closer look once I'm
switching to kronolith - probably soon. Currently Kolab does not
depend on Kronolith for the management of resources. Do you think it
would be possible to move the Resource library parts into the Horde
framework? Then I could rip my resource code out of the Kolab_Filter
package - where it does not belong anyway - and try to merge the two.

> I'm honestly not sure how this would work with resources not having  
> to be user accounts.

Kolab integrates the resource management into the MTA mailpath. Once a
mail contains an iTip part and is addressed to a resource account
(e.g. resource at example.org) it will be converted into an event for the
resource (as long as the resource allows automatic booking).

For the Horde variant of resources I could imagine using the same
approach but work with "+"-addressing. So if somebody from the outside
wishes to book "room101" then he would add the attendee
resources+room101 at example.org.

> Both specifically to Kolab, and in a more general sense in allowing  
> the use of iTip notifications for resource request.  I suppose that  
> if each resource had it's own email account (and corresponding horde  
> account) the resource could be given an email address as it's  
> identifier, then any iTip notifications would be send to the  
> resources's email address...but that would require a user to login  
> to horde as the resource to accept it, right?

That depends. You've already implemented different types of behavior
for the resources. If a resource does always accept an invitation
(even if overbooking the resource) or if it only rejects if there is a
conflict then you can handle all incoming iTip invitations
automatically. As long as an iTip message can be consumed directly
there is no need for a real user to log in and check the incoming
invitations. So I think it should be no real problem to implement at
least the core functionality here. I believe booking with rejection if
there is a conflict is what most people want to have with resources.

What I did not consider now are access restriction. But I guess it
should not be too hard to provide different rights to different mail
adresses if you don't want the whole word to send your conference room
invitations.

Cheers,

Gunnar