[dev] Kronolith resources

[Michael Rubinsky]

Quoting Gunnar Wrobel <p at rdus.de>:

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

Ah. That sounds much better :)

Shouldn't be too much of an issue adding support for resources to  
Kronolith's API. I've got to finish fleshing out some stuff  
internally, but I can work on adding it after the internals are  
working. I'm guessing we would basically need a method to request a  
resource booking that would take an iCalendar and have it return some  
kind of acceptance value?  If/when you know what other methods we  
would need, please let me know so I don't overlook anything.

> 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 agree. I think that would be too messy. Kronolith can take care of  
the auto-acceptance, conflict management etc... and I suppose your  
Kolab driver could do the same for the kolab resources.


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

The iTip Mime viewer?  Cool. My concern was more about parsing the  
iTip out of the email addressed to the resource. Not too much  
experience in that area :)

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


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