Closed Bug 357397 Opened 13 years ago Closed 12 years ago

[proto] support WCAP server invitations

Categories

(Calendar :: General, defect)

x86
Windows XP
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: thomas.benisch, Assigned: michael.buettner)

Details

Attachments

(2 files, 2 obsolete files)

For a WCAP server, e.g. the Sun Java System Calendar Server, event invitations
need to be supported. For more details see

http://wiki.mozilla.org/Calendar:Server_Based_Invitation_Handling
Attached patch WCAP server invitations (part1) (obsolete) — Splinter Review
This part of the patch contains all new files for the prototypes folders.
Attached patch WCAP server invitations (part2) (obsolete) — Splinter Review
This part of the patch contains the changes to the lightning chrome.manifest
and jar.mn files.
Attachment #242869 - Flags: first-review?(dmose)
Out of curiousity, what about shipping these files in the additional xpi, since they can't be easily used without that anyway?
(In reply to comment #3)
> Out of curiousity, what about shipping these files in the additional xpi, since
> they can't be easily used without that anyway?
First of all, which additional xpi do you mean? In case you mean the lightning-wcap.xpi, as far as i understood it, this is a temporary solution anyway. Second, this invitations dialog can easily be extended to handle the general case. Granted, for now it handles server based invitations only, but this doesn't mean it can't be extended for the general case.
Comment on attachment 242869 [details] [diff] [review]
WCAP server invitations (part2)

removed dmose from first-review
Attachment #242869 - Flags: first-review?(dmose)
Comment on attachment 242869 [details] [diff] [review]
WCAP server invitations (part2)

added mvl for first-review
Attachment #242869 - Flags: first-review?(mvl)
Comment on attachment 242869 [details] [diff] [review]
WCAP server invitations (part2)

>+++ mozilla/calendar/lightning/chrome.manifest	2006-10-19 12:58:12.000000000 +0200
>+overlay chrome://lightning/content/messenger-overlay-sidebar.xul 
chrome://lightning/content/sun-messenger-overlay-sidebar.xul

SO, that means that everybody will see the link, even if they don't use wcap? I think we should hide the link if no calendar supports invitations.
(In reply to comment #7)
> SO, that means that everybody will see the link, even if they don't use wcap? I
> think we should hide the link if no calendar supports invitations.

No, the invitations link is only visible, if

1.) the calendar.prototypes.wcap preference is set to true and
2.) a WCAP calendar is subscribed

The relevant code you'll find in sun-messenger-overlay-sidebar.js
in the WCAP server invitations patch (part1).
By default the invitations label has the attribute hidden, which
is removed in the load handler of the document, if 1.) and 2.)
are true.

I think this approach is not optimal, but I didn't find another
way. An optimal approach would be e.g. register this overlay
only, if a certain preference is set. Any ideas?
(In reply to comment #8)
> I think this approach is not optimal, but I didn't find another
> way. An optimal approach would be e.g. register this overlay
> only, if a certain preference is set. Any ideas?
> 
There's http://developer.mozilla.org/en/docs/DOM:document.loadOverlay which might be useful here.
(In reply to comment #9)
> (In reply to comment #8)
> > I think this approach is not optimal, but I didn't find another
> > way. An optimal approach would be e.g. register this overlay
> > only, if a certain preference is set. Any ideas?
> > 
> There's http://developer.mozilla.org/en/docs/DOM:document.loadOverlay which
> might be useful here.

Thanks for this hint. The loadOverlay function is exactly what I need.
Instead of adding the overlay file to the chrome.manifest,
I can add the following lines to the end of the ltnOnLoad function:

if (getPrefSafe("calendar.prototypes.wcap", false)) {
    document.loadOverlay(
        "chrome://lightning/content/sun-messenger-overlay-sidebar.xul", null);
}

The pros and cons of this alternative approach are:
pros:
+ overlay is not loaded, if calendar.prototypes.wcap pref is not set,
  e.g. in non-wcap-lightning
+ no additional chrome.manifest entry
cons:
- According to the documentation this API is not frozen and will change
  in 2.0 timeframe.
- additional code in ltnOnLoad function

My main concern is the unstable API.

TBE->MVL: What do you think?
I don't really mind unstable api's. We use non-frozen interfaces all over the place...
This part of the patch contains all new files for the prototypes folders.
Attachment #242868 - Attachment is obsolete: true
This part of the patch now uses the document.loadOverlay() function at
the end of the ltnOnLoad function and contains the changes to the
lightning jar.mn file.
Attachment #242869 - Attachment is obsolete: true
Attachment #245557 - Flags: first-review?(mvl)
Attachment #242869 - Flags: first-review?(mvl)
Comment on attachment 245557 [details] [diff] [review]
WCAP server invitations (part2) v2

You also need to include the files in the sunbird jar.mn files.
Attachment #245557 - Flags: first-review?(mvl) → first-review-
(In reply to comment #14)
> (From update of attachment 245557 [details] [diff] [review] [edit])
> You also need to include the files in the sunbird jar.mn files.

I didn't add the files to the Sunbird jar.mn files by intention.

Concerning WCAP support our current focus is Lightning, e.g.
the new prototype event dialog is also available for Lightning only.
Therefore this patch implements WCAP server invitations for
Lightning only.
Comment on attachment 245557 [details] [diff] [review]
WCAP server invitations (part2) v2

Asking for review again.
Attachment #245557 - Flags: first-review- → first-review?(mvl)
We should keep feature parity between sunbird and lightning as much as possible. Is there any reason besides lightning being your main goal for not adding the files to sunbird?
(In reply to comment #17)
> We should keep feature parity between sunbird and lightning as much as
> possible. Is there any reason besides lightning being your main goal for not
> adding the files to sunbird?

Although in principal the major part of the code can be shared between
Lightning and Sunbird, there is also some Lightning specific code.
That's the sidebar overlay code in sun-messenger-overlay-sidebar.xul,
sun-messenger-overlay-sidebar.js and sun-lightning.dtd.
In order to get the feature working in Sunbird this would need some
additional work and a different set of Sunbird specific files.

I fully understand your argument about feature parity between Lightning
and Sunbird, nevertheless I think it was accepted, that we focus on
Lightning with our WCAP features first.
Comment on attachment 245557 [details] [diff] [review]
WCAP server invitations (part2) v2

If it is not much work to port the patch to sunbird, I would prefer to do that now. Otherwise, you need to dive into the code later and then it will be much more work.

But i'll leave that decision to you.
r=mvl
Attachment #245557 - Flags: first-review?(mvl) → first-review+
(In reply to comment #19)
> (From update of attachment 245557 [details] [diff] [review] [edit])
> If it is not much work to port the patch to sunbird, I would prefer to do that
> now. Otherwise, you need to dive into the code later and then it will be much
> more work.
> 
> But i'll leave that decision to you.

I'll put porting the patch to Sunbird on my TODO list.
patch checked in on HEAD and MOZILLA_1_8_BRANCH
Summary: support WCAP server invitations → [proto] support WCAP server invitations
Assignee: thomas.benisch → michael.buettner
Closing this bug since the patch has been checked in. Porting the code to Sunbird can be handled in a spin-off bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.