Closed Bug 370148 Opened 14 years ago Closed 13 years ago

API enhancement: Providing free-busy information

Categories

(Calendar :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dbo, Assigned: dbo)

References

Details

(Whiteboard: [roadmap 0.7])

Attachments

(3 files, 5 obsolete files)

Attached patch calIFreeBusyProvider (obsolete) — Splinter Review
Proposing calIFreeBusyProvider; relies on calIRequest proposal from bug 329034.
Attachment #254804 - Flags: first-review?(dmose)
Assignee: nobody → daniel.boelzle
Attachment #254804 - Flags: first-review?(dmose)
Flags: blocking-calendar0.7+
Whiteboard: [roadmap 0.7]
Attached patch calIFreeBusyProvider (obsolete) — Splinter Review
Adding calIFreeBusyProvider, calIFreeBusyPeriod although it's still to be figured out where providers should implement that interface. Implementing it right next to calICalendar is somehow not intended, because it provides free-busy information for arbitrary users (calIds) in a multi-user calendar environment. So this makes more sense to be implemented at a separate instance, but this will be subject of another bug. This bug should only clarify the overall API + types for free-busy lookup.
Attachment #254804 - Attachment is obsolete: true
Attachment #277118 - Flags: review?(browning)
note: We possibly want a shared implementation for calIFreeBusyPeriod (like calPeriod); calId/freeBusyType should be read-write attributes then.
It took me a while looking for a way to get the start and end date, before I noticed that calIFreeBusyPeriod inherits from calIPeriod. That should be documented a bit more explicit. (Is the inheritance really a good thing here btw?)

With those interfaces, you can specify either free or busy as paramater. But in the reply, there are four options for those fields. I think that you either need to document what 'free' and 'busy' means in terms of those four, or allow setting all four in the query (likely as a combined flag) 
(In reply to comment #3)
> It took me a while looking for a way to get the start and end date, before I
> noticed that calIFreeBusyPeriod inherits from calIPeriod. That should be
> documented a bit more explicit. (Is the inheritance really a good thing here
> btw?)
I think it's sensible to inherit here, because it actually models a true is-a relationship, thus I chose to call it calIFreeBusy*Period*.

> With those interfaces, you can specify either free or busy as paramater. But in
> the reply, there are four options for those fields. I think that you either
> need to document what 'free' and 'busy' means in terms of those four, or allow
> setting all four in the query (likely as a combined flag) 
Good point; that boolean parameter specifies to filter FREE periods or BUSY_* periods. The main reason I chose only a boolean parameter was simplicity: I couldn't imagine why callers would want only a subset of the busy information.
Attached patch calIFreeBusyProvider (obsolete) — Splinter Review
I just recalled mvl's comment about inheriting from calIPeriod and slightly agree with his concern: there is one problem which makes calIPeriod not a good citizen for inheritance, i.e. attribute icalString. That attribute could not be used for a free-busy period, because iCalendar's FREEBUSY is modelled as a multi-value (period list) *property* whereas calIPeriod models an iCalendar value type. However, we could add

attribute calIcalProperty icalProperty;

to the interface, but we still need to make clear that calIPeriod::icalString just returns the FREEBUSY's value, just like calIcalProperty::valueAsIcalString which would be a better name.

Because of this mixed up situation, I changed the interface to use plain composition: it contains the free-busy interval (period).

Bruno, it seems you are quite busy, so I am shifting the review over to mvl.
Attachment #277118 - Attachment is obsolete: true
Attachment #277689 - Flags: review?(mvl)
Attachment #277118 - Flags: review?(browning)
Status: NEW → ASSIGNED
Comment on attachment 277689 [details] [diff] [review]
calIFreeBusyProvider

>+interface calIFreeBusyProvider : nsISupports
>+     * @param aListener   called with an array of calIFreeBusyInterval objects

You need to specify this a bit better. Will it be an nsIArray? (I don't really know any other way to pass an array through nsIVariant, but maybe I'm wrong. So please specify what it is)

>+                                       in unsigned long aBusyTypes,
>+                                       in boolean aBusy,

I think that aBusy is leftover?

r- for now, because i want the array thing to be specified (and have  asecond look at how it will be specified). But that's really all, the rest looks good.
Attachment #277689 - Flags: review?(mvl) → review-
(In reply to comment #6)
> (From update of attachment 277689 [details] [diff] [review])
> >+interface calIFreeBusyProvider : nsISupports
> >+     * @param aListener   called with an array of calIFreeBusyInterval objects
> 
> You need to specify this a bit better. Will it be an nsIArray? (I don't really
> know any other way to pass an array through nsIVariant, but maybe I'm wrong. So
> please specify what it is)
While scripting handles array (de)capsulation from/to variant seamlessly, native code could use nsIVariant::getAsArray() resp. nsIWritableVariant::setAsArray(); IMO sufficiently documented.
removed the leftover
Attachment #277689 - Attachment is obsolete: true
Attachment #277899 - Flags: review?(mvl)
Comment on attachment 277899 [details] [diff] [review]
calIFreeBusyProvider

r=mvl, since I forgot about getAsArray()...
Attachment #277899 - Flags: review?(mvl) → review+
Landed interface on HEAD and MOZILLA_1_8_BRANCH.
Target Milestone: --- → 0.7
So next question is how the event dialog accesses a calIFreeBusyProvider when inviting other people? Due to the fact that free-busy support could be bound to an open session, IMO the most flexible way would be an attribute of calICalendar. Opinions?
Why is freebusy tied to a certain calendar? I should be able to read a freebusy file (ics style) while adding an event to my storage calendar. The information is more tied to an person getting invited then to the one that invites. I would think that binding the information to an person makes more sense, thus the freebusy information would be in an addressbook entry.
For what it's worth, there was a little bit of discussion in the forums about using the address book for this purpose:
http://forums.mozillazine.org/viewtopic.php?t=572616
(In reply to comment #12)
Getting free-busy infirmation is diverse, and IMO calICalendar provides us the most flexibility. At least WCAP (and I could imagine Google/CalDAV too) need an established session (logged in user) to get free-busy information, because obtaining free-busy information is often under access control. Regarding CalDAV scheduling, the organizer of an event requests free-busy by posting to its outbox. Regarding ics, free-busy using the addressbook makes perfectly sense, because scheduling is performed via iTIP/iMIP, but this won't hinder the ics provider to implement that lookup.
I understand that re-using the session from the calendar is a nice thing to do. But to me this sounds wrong on a conceptual level. The information stored in calICalendar is my data. It applies to me. But when I add an attendee, that data can be stored anywhere else. It might be on the same server, it might be on some freebusy file, it might on the same type of server but not the same server, anything. So binding the freebusy information to the calendar in which I want to store my data does not make sense to me.
I think we need to link the information somewhere else. It might then go back to the calICalendar provider in order to really get the information, but it doesn't need to.
I suggested the addressbook, because that is what stores information about other people, not because ics can use iMIP.
(Just for completeness' sake: the base CalDAV spec defines how to get freebusy information by the REPORT method; obtaining freebusy info by POSTing to an inbox is part of the as-yet-unfinalized CalDAV Scheduling spec)

While re-using an existing session is a good thing to do if possible, that's not always going to be possible, perhaps not even often possible. I imagine that most of the freebusy requests I would pose would be to systems to which I am not authenticated prior to the freebusy request, and to which I cannot authenticate as principal. And there will be cases where freebusy information will be available without any authentication. So I'm uncomfortable with any assumption of a pre-exising session.

I share mvl's migivings about tying this data to a particular calendar, at least to an existing one that appears in the calendar list: conceptually it seems to be the wrong place to put it. The addressbook makes more sense to me.

It also seems to me that when we start thinking about scheduling we're entering a realm where there are security concerns that we haven't had before. While freebusy info is often under some form of access control, it is much less sensitive than the full calendar data that's handled by the provider - it's kind of the /purpose/ of freebusy data to be usable in security contexts where the full data shouldn't be. Should our freebusy code be somehow separate from the code that handles the full dataset? It bears thinking about. Security also poses us with code-placement issues: I can image contexts in which admins want users to be able to exchange scheduling information with users elsewhere but not to interact with actual calendar accounts elsewhere. Packaging freebusy providers separately from calendar providers would make enforcing such policies easier, and Sunbird/Lightning a more attractive option in such contexts.

Just some quick fly-by comment: While the address book might be a good place to tie this to, what do we do in Sunbird?

In gdata, freebusy information is tied to a calendar, not a person. If freebusy info is tied to the address book, then you would have to create an address book entry for each calendar you want to see freebusy information for. While this is fine for the users default calendar, where the calendar name is his email, the non-default calendars have a name like 3a9b523a89b582c039f58e32d5@group.calendar.google.com which does not forward email to the default user.
(In reply to comment #15)
> I understand that re-using the session from the calendar is a nice thing to do.
> But to me this sounds wrong on a conceptual level. The information stored in
> calICalendar is my data. It applies to me. But when I add an attendee, that
> data can be stored anywhere else. It might be on the same server, it might be
> on some freebusy file, it might on the same type of server but not the same
> server, anything. So binding the freebusy information to the calendar in which
> I want to store my data does not make sense to me.
It wasn't meant to bind that information to the organizer's calendar, but the freeBusyProvider attribute simply serves as the entry point to get the free-busy interface. calIFreeBusyProvider should/need not be implemented with calICalendar.

> I think we need to link the information somewhere else. It might then go back
> to the calICalendar provider in order to really get the information, but it
> doesn't need to.

Another possibility I thought of was some kind of a calISharedContext to hold that attribute, e.g.

calICalendar {
...
    readonly attribute calISharedContext sharedContext;
...
}

calISharedContext {
    readonly attribute freeBusyProvider;
...[searchForCalendar (another feature of "shared" nature)]
}

or without a separate calIFreeBusyProvider interface:

calISharedContext {
   getFreeBusyIntervals();
...[searchForCalendar (another feature of "shared" nature)]
}

But this only means another level of indirection using a "shared" context.

> I suggested the addressbook, because that is what stores information about
> other people, not because ics can use iMIP.
As Philipp already mentioned, your address book need not have all attendees you want to invite.
But back to my primary point: It's no problem using the address book for providers like ics. It's just that callers need a single entry point to get to that free-busy interface and IMO it's still the most flexible way that they are using the organizer's calendar/account to get that interface. IMO the core problem is once another time that there is no global directory and infrastructure for attendee free-busy lookup; similar to the coming "search for calendar" feature.
(In reply to comment #16)
> (Just for completeness' sake: the base CalDAV spec defines how to get freebusy
> information by the REPORT method; obtaining freebusy info by POSTing to an
> inbox is part of the as-yet-unfinalized CalDAV Scheduling spec)
Please think a minute about that move and characteristic in CalDAV scheduling(!) It makes retrieving free-busy information fairly easy, because it sticks to the organizer's point of view: I want to schedule a meeting and need to get free-busy information doing so. I don't need to collect free-busy URLs or anything else. I just get it by simply posting to my outbox.

> While re-using an existing session is a good thing to do if possible, that's
> not always going to be possible, perhaps not even often possible. I imagine
> that most of the freebusy requests I would pose would be to systems to which I
> am not authenticated prior to the freebusy request, and to which I cannot
> authenticate as principal. And there will be cases where freebusy information
> will be available without any authentication. So I'm uncomfortable with any
> assumption of a pre-exising session.
Please don't get me wrong. Comment #14 just stated the session thing regarding WCAP/Google. My point was that we need a single point of access from the client's perspective.

> I share mvl's migivings about tying this data to a particular calendar, at
> least to an existing one that appears in the calendar list: conceptually it
> seems to be the wrong place to put it. The addressbook makes more sense to me.
I've commented on that above; calIFreeBusyProvider/calISharedContext or the like are higher-level than calICalendar. calIFreeBusyProvider/calISharedContext are accessed by attribute, not meant to be implemented at the same object with calICalendar.

> It also seems to me that when we start thinking about scheduling we're entering
> a realm where there are security concerns that we haven't had before. While
> freebusy info is often under some form of access control, it is much less
> sensitive than the full calendar data that's handled by the provider - it's
> kind of the /purpose/ of freebusy data to be usable in security contexts where
> the full data shouldn't be. Should our freebusy code be somehow separate from
> the code that handles the full dataset? It bears thinking about. Security also
Yes, possibly. But on the downside, it makes deployment and configuration much harder.

> poses us with code-placement issues: I can image contexts in which admins want
> users to be able to exchange scheduling information with users elsewhere but
> not to interact with actual calendar accounts elsewhere. Packaging freebusy
> providers separately from calendar providers would make enforcing such policies
> easier, and Sunbird/Lightning a more attractive option in such contexts.
[I hope I get you right on the last section.]
With regard to CalDAV scheduling, I don't see that urging problem, because all that functionality is hidden behind the server's interface, which can enforce security policies. If you think of free-busy gateways to other calendar systems beyond the user's primary server, AFAIR parts of that have been discussed at CalConnect, about that CalDAV/CalDAV scheduling has explicitly been designed for inter-calendar system communication.
> Please don't get me wrong. Comment #14 just stated the session thing regarding
> WCAP/Google. My point was that we need a single point of access from the
> client's perspective.

What do you mean with a 'point of access'? access to what? And what kind of access: knowledge about things like an url or more like authorization issues?


I think that there must be multiple implementations of the freebusy provider, just like we have for calendar providers. The implementation to use depends on what calendar server the one being invited uses. There should be some kind of mapping from attendee to provider. My idea was to use the addressbook for that mapping, because we can store attendee info in there. But some other kind (for sunbird) would work too.

Now, what I don't understand: is the proposed addition to calICalendar meant to be to get information about a specific attendee, or is it just to instantiate a freebusy provider that happens to use the same server, but is not tied to any attendee?
Related to that: How does the event dialog get the information about the attendees?
(In reply to comment #20)
> > Please don't get me wrong. Comment #14 just stated the session thing regarding
> > WCAP/Google. My point was that we need a single point of access from the
> > client's perspective.
> 
> What do you mean with a 'point of access'? access to what? And what kind of
> access: knowledge about things like an url or more like authorization issues?
API access to free-busy information, i.e. access to a suitable calIFreeBusyProvider.

> I think that there must be multiple implementations of the freebusy provider,
> just like we have for calendar providers. The implementation to use depends on
> what calendar server the one being invited uses. There should be some kind of
> mapping from attendee to provider. My idea was to use the addressbook for that
> mapping, because we can store attendee info in there. But some other kind (for
> sunbird) would work too.
> 
> Now, what I don't understand: is the proposed addition to calICalendar meant to
> be to get information about a specific attendee, or is it just to instantiate a
> freebusy provider that happens to use the same server, but is not tied to any
> attendee?
The latter. calIFreeBusyProvider isn't tied to a specific attendee, i.e. getFreeBusyIntervals(calId/rfc822addr).
calICalendar::freebusyProvider references a free-busy provider to be used in a scheduling scenario for that calendar (the organizer will host the originating event in that calendar).

> Related to that: How does the event dialog get the information about the
> attendees?
1. User types in attendee addresses.
2. Event dialog gets a fitting free-busy provider from organizer's calendar (i.e. the one that the event is about to be saved into).
(In reply to comment #21)
> 1. User types in attendee addresses.
> 2. Event dialog gets a fitting free-busy provider from organizer's calendar
> (i.e. the one that the event is about to be saved into).

If I understand this correctly, this means that every provider needs to know that userA has a freebusy file published at some url, while userB uses a wcap server and userC does caldav scheduling. Won't it be better to have that knowledge in some central place?
I think that your point is that some providers can sotre that knowledge. But a whole lot can not do that! Maybe we need a flag or something?
There is no central infrastructure you could use for free-busy lookup, it is usually bound to a specific calendar system (CalDAV, WCAP, Google, MAPI, ...).
I don't think we need a flag, because that attribute could be null, indicating that it isn't available.
BTW: I could imagine the local storage and ics provider to implement an addressbook/URL-based free-busy provider like you've sketched. Even if a "static" one (meaning all ics and storage provider instances point to that same free-busy provider), it IMO doesn't hurt the design.
But if you request the calendar in which you are going to store the vent, how about this situation: the user has access to a wcap calendar that know about freebusy of other users. The user want to create an event and invite those other peoples, but wants to store the event in his local storage calendar. How would that work? I don't see a reason for not asking the wcap server, but in the proposal that's not possible.
I don't understand your scenario. In your first sentence you write the destination calendar is going to be a wcap one, while in the second sentence you write it'll be a local one.
IMO the proposal is flexible. The provider could even fall back to a addressbook/centralized/yet-to-come free-busy infrastructure if the provider itself can't provide the demanded free-busy information of some user.
My point in comment 24 is that you said that the UI will ask the calendar in which the event will be stored about freebusy information. But if you are going to store an event in a local storage calendar, but want to invite somebody that your wcap calendar has freebusy information about, it would be annoying if you can's see the freebusy info, just because you are storing the event in the wrong calendar.

But i think i've tried to say that a couple of times now. Maybe I just don't understand the proposal correctly?

My proposal would be to have a central registry, that can point to freebusy providers based on the attendee and/or the calendar and/or other info.
I just currently don't see a real need for a separated free-busy provider registry; it would require to expose session management to some extend, which could currently be well hidden in the providers. Even if we will build that up one day, it could coexist.

I think CalDAV's approach is pretty elegant, modeling inbox and outbox as just another of the user's collections on the server. Regarding our API, I was just suggesting one could access those special "channels" (which have no calendar context, but an account context) either directly (per attribute) or via another level of indirection, a "shared context" object (comment #18).

I'd like you to comment on my (well also repeatedly stated) argument about flexibility: UI could use a calendar's free-busy provider, or (if null) do a "global" free-busy lookup iterating over every calendar's free-busy provider. The storage provider could implement a free-busy provider based on the addressbook, Google/CalDAV/WCAP using a configured server and user's session... What's so bad about it? It's open for fallbacks.
Having a central place that talks to all the providers, instead of that being spreak out over all the consumers is just as flexible, right?

And only asking the current calendar/provider about freebusy i it happens to be able to supply fb information would be not flexible. If I store my event in a wcap calendar (which happens to have fb info), but want to invite somebody of which i have fb info on my caldav calendar, would not be good. You wan't see the info, while you do have it. Not flexible.

I think we mostly agree on the approach. The only difference I see is that I propose to have a central place that can loop over all the providers, while you want to leave that up to the consumer (the UI, most likely, but there might be other places. think extensions)

And I never really proposed to have a fb provider based on the addressbook. I only proposed that there should be a provider based on ics freebusy files. The location of those files can be stored in the addressbook, but that's an implementation detail. This provider is not linked to storage: the ics provider would also use it. Would be a waste to implement it twice, so it need somewhere more shared.

I also proposed that there is some location that has a mapping of invitee to type of freebusy provider. And that could again be stored in the addressbook, but that also is an implementation detail.
I think we finally come together.

(In reply to comment #28)
> Having a central place that talks to all the providers, instead of that being
> spreak out over all the consumers is just as flexible, right?
> 
> And only asking the current calendar/provider about freebusy i it happens to be
> able to supply fb information would be not flexible. If I store my event in a
> wcap calendar (which happens to have fb info), but want to invite somebody of
> which i have fb info on my caldav calendar, would not be good. You wan't see
> the info, while you do have it. Not flexible.
I never doubted that, but suggested consumers could iterate over all available fb providers.

> I think we mostly agree on the approach. The only difference I see is that I
> propose to have a central place that can loop over all the providers, while you
> want to leave that up to the consumer (the UI, most likely, but there might be
> other places. think extensions)
I agree with you. If this is our difference, I am all for it to add a service that takes care of iterating the configured providers, multiplexing fb queries. What still needs to be discussed is whether precendence is important (or not)? Meaning if fb information is available from multiple fb providers, should we accumulate all, or could a fb provider enforce precedence?

> And I never really proposed to have a fb provider based on the addressbook. I
> only proposed that there should be a provider based on ics freebusy files. The
> location of those files can be stored in the addressbook, but that's an
> implementation detail. This provider is not linked to storage: the ics provider
> would also use it. Would be a waste to implement it twice, so it need somewhere
> more shared.
no doubt.

> I also proposed that there is some location that has a mapping of invitee to
> type of freebusy provider. And that could again be stored in the addressbook,
> but that also is an implementation detail.
What do you mean by "different type of freebusy provider"?
A central free-busy service, multiplexing free-busy requests to all added fb providers.
Attachment #278050 - Attachment is obsolete: true
Attachment #279446 - Flags: review?(mvl)
Comment on attachment 279446 [details] [diff] [review]
free-busy service

looks good. r=mvl
Attachment #279446 - Flags: review?(mvl) → review+
Attachment #281336 - Flags: review?(michael.buettner)
Comment on attachment 281336 [details] [diff] [review]
calFreeBusyService implementation, WCAP and UI adoption, some helpers

calFreeBusyService.js as well as the related changes look just fine, no complaints.

>+bin\js\calFreeBusyService.js
Even added to packages-static, great.

>+++ mozilla/calendar/prototypes/wcap/sun-calendar-event-dialog-freebusy.xml
The changes to ...event-dialog-freebusy.xml are mostly in order to adopt the interface changes.

>-      <field name="mCalendar">null</field>
This is indeed no longer required, as I previously needed to quire for calIWcapProvider.

>+to be discussed: IMO this part could vanish since free-busy lookup is now performed globally
>+                 over all available free-busy providers
I suggest to remove this method.

>+                          var request = fbService.getFreeBusyIntervals(
>+                              calid, start, end, Components.interfaces.calIFreeBusyInterval.BUSY_ALL,
>+                              this.mFreeBusyListener);
>+                          // XXX tod be discussed: does this work if the request answeres within
>+                          //                       getFreeBusyIntervals, i.e. in a sync fashon?
>+                          this.mFreeBusy[request.id] = i;
>+                          this.mPendingRequests.push(request);
This is indeed problematic. getFreeBusyIntervals() gets executed for each row of the control, so it needs to remember what request has been fired for which row. Currently this code assumes that getFreeBusyIntervals() returns first before notifying the listener. The key is that the control remembers the sequence number (id) of the returned operation object in order to match the calls fired on the listener. If this listener gets called before getFreeBusyIntervals() returns this code won't work. A possible solution could be to pass a sequence number to getFreeBusyIntervals() that can be used to identify the result. Since this involves a change to the interface it's probably something that should be changed now instead of being postponed. As long as the free/busy service answers asynchronously it will work. But I leave this decision up to you. r=mickey.
Attachment #281336 - Flags: review?(michael.buettner) → review+
(In reply to comment #33)
> >+                          // XXX tod be discussed: does this work if the request answeres within
> >+                          //                       getFreeBusyIntervals, i.e. in a sync fashon?
> >+                          this.mFreeBusy[request.id] = i;
> >+                          this.mPendingRequests.push(request);
> This is indeed problematic. getFreeBusyIntervals() gets executed for each row
> of the control, so it needs to remember what request has been fired for which
> row. Currently this code assumes that getFreeBusyIntervals() returns first
> before notifying the listener. The key is that the control remembers the
> sequence number (id) of the returned operation object in order to match the
> calls fired on the listener. If this listener gets called before
> getFreeBusyIntervals() returns this code won't work. A possible solution could
> be to pass a sequence number to getFreeBusyIntervals() that can be used to
> identify the result. Since this involves a change to the interface it's
> probably something that should be changed now instead of being postponed. As
> long as the free/busy service answers asynchronously it will work. But I leave
> this decision up to you. r=mickey.
> 

Mickey, I don't think we should pollute the interface with that. An easy alternative approach would be to pass different listener objects for every request or use the requested calId. I think we need to fix this before this service gets in, because we can't rely on freebusy providers built on top of 0.7 working asynchronously.
(In reply to comment #34)
> Mickey, I don't think we should pollute the interface with that. An easy
> alternative approach would be to pass different listener objects for every
> request or use the requested calId. I think we need to fix this before this
> service gets in, because we can't rely on freebusy providers built on top of
> 0.7 working asynchronously.
I don't think that this 'pollutes' the interface, it simply allows to differentiate between different calls. Round-tripping a user supplied sequence number is an efficient and clean solution to the problem. Always passing a new listener object strikes me as being an inefficient workaround and deciding on calid's won't work for the case where the same calid has been used on different lines (i.e. the same email address on different rows should not confuse the control).
(In reply to comment #35)
> I don't think that this 'pollutes' the interface, it simply allows to
> differentiate between different calls. Round-tripping a user supplied sequence
> number is an efficient and clean solution to the problem. Always passing a new
I disagree, because it's strictly not needed and just bloats the interface with a "context/unspecified/justPassed" parameter.

> listener object strikes me as being an inefficient workaround and deciding on
> calid's won't work for the case where the same calid has been used on different
> lines (i.e. the same email address on different rows should not confuse the
> control).
W.r.t. using the same listener for every call, I see no problem using the calId: the code could iterate the lines and fill in the information. But after all, I don't see any efficiency problems at all here since I suspect an average number of 5 participants, so I'd go and use separate listener objects.
- using separate listeners for every line
- cleanup
Attachment #281336 - Attachment is obsolete: true
Attachment #281483 - Flags: review?(michael.buettner)
Comment on attachment 281483 [details] [diff] [review]
calFreeBusyService implementation, WCAP and UI adoption, some helpers

r=mickey
Attachment #281483 - Flags: review?(michael.buettner) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
No longer blocks: 387997
Verified free-busy works for WCAP.
Status: RESOLVED → VERIFIED
Duplicate of this bug: 322383
You need to log in before you can comment on or make changes to this bug.