[dev] Kronolith resources

[Michael Rubinsky]

Quoting Gunnar Wrobel <p at rdus.de>:

> 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 suppose that it's possible, but there are a number of issues that  
come to mind:

Currently, resources are basically just another internal kronolith  
calendar (with the calendar_id prefixed with 'resource_').  When an  
event is saved, all resources attached to the event are reviewed  
immediately, and if the invitation is accepted, the event is updated  
with the resource's response, the event is added to the resource's  
calendar and stored in the kronolith_objects table. In fact, the  
resource storage driver is just an extension of the SQL driver.   
Obviously, it wouldn't be too difficult to pull out the resource  
storage driver and put it into Horde, thus allowing us to have  
separate SQL and Kolab resource drivers. (Though this would mean the  
addition of database tables, essentially duplicating the  
kronolith_events table). What I'm thinking _will_ be an issue though  
is allowing admins to manually manage the resource's calendar. Right  
now, an admin can add events manually to a resource's calendar just  
like an event is added to any other internal kronolith  
calendar...since these calendars *are* internal kronolith calendars.  
(While these events won't be associated with any events like an  
attendee, it would be useful for blocking out time for say,  
maintenance or whatever).  Admins are also able to delete events from  
the resource's calendar (and if that event corresponds to an  
invitation that has already been accepted, that invitation is  
revoked/denied). I'm afraid that pulling the storage code out of  
Kronolith would essentially make these calendars remote calendars and  
more difficult to manage directly in kronolith.

I'm willing to give it a try though, and see what happens with it. My  
concern is that this work is for a client, and there is a time issue  
here.  I could probably get the resource stuff pulled out into Horde  
if there are no big issues, but the iTip stuff you describe below I'm  
almost positive I won't be able to implement in time.  So...if I can  
pull out the storage, I'll make that work as it does now in kronolith  
with the thought that the iTip stuff can come later.

Jan/Chuck, any thoughts on this?



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

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin