[dev] Kronolith resources

[Gunnar Wrobel]

Quoting Michael Rubinsky <mrubinsk at horde.org>:

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

That would probably be too much. My original statement "move the  
Resource library parts into the Horde framework" wasn't quite clear. I  
believe Resources are indeed an integral part of Kronolith as they are  
solely concerned with events and that is also what Kronolith is about.  
So I think the tables should remain there.

What I was thinking about could probably be reduced to accessing the  
resources via the Kronolith API. If there'd be a Horde_Resource  
package its primary intention would be to wrap the resource access.  
The Horde driver would use the Kronolith API and the Kolab driver  
would directly access the Kolab IMAP storage.

On top of that the iTip-Handling would go into into this  
Horde_Resource package.

I'm not certain if it would be a benefit to have general conflict  
handling in this package. Then Kronolith would need to access its own  
resources via the package and its API for booking a resource. That  
might be too much.

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

We do already have two iTip-handling code sections. The original one  
in IMP and the one in the Kolab_Filter package (which has been derived  
from the original version in IMP). It shouldn't be much a problem for  
me to combine the two in a potential Horde_Resource package.

Cheers,

Gunnar

>
> 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
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090921/4c730b26/attachment.bin>