http://www.dnalounge.com/backstage/log/2005/01.html causes the "Live Bookmark" icon to show up because it says <LINK REL="alternate" TYPE="application/rss+xml" TITLE="RSS" HREF="../latest.rss"> But http://www.dnalounge.com/calendar/2005/01.html says <LINK REL="alternate" TYPE="text/calendar" TITLE="iCal" HREF="webcal://www.dnalounge.com/calendar/dnalounge.ics"> and the Live Bookmark icon doesn't show up there. I think it should! I do happen to have both RSS and ICS versions of the calendar, but in my experience, RSS of calendars just isn't very useful -- that's what ICS is for. So it would be nice if you did auto-discovery of ICS files as well, handing the "webcal" URL off to the calendar module so that the calendar could be subscribed to more easily.
Putting it in the Live Bookmarks discovery icon doesn't seem like a very good idea to me - bad discovery (I already subscribe to your RSS, why would I ever look in there again?) and useless code for people without the calendar installed. Wouldn't it work just as well, while not impacting non-calendar users, to have the calendar install a Firefox extension that adds another calendar discovery statusbar icon? It's trivial to do that way, just add a listener for DOMLinkAdded and they're handed to you on a silver platter.
> bad discovery (I already subscribe to your RSS, why would I ever > look in there again?) I don't understand what you mean. Isn't the point of "auto-discovery" to discover alternate presentations of the page you're looking at? This is exactly such a thing. Mozilla at least had the "More / Other Versions" menu on the Site Navigation Bar; Firefox has (as far as I can tell) no way to present the various non-navigation LINK REL types at all, except by reading the page source. > and useless code for people without the calendar installed. Useless code for people who don't use *any* calendar, perhaps. I think this belongs in Firefox and not in the calendar because this should work even if you don't use the Firefox calendar exension; for example, a Mac user who uses Firefox and iCal; or a Linux user who uses Firefox and Evolution. The "webcal" URL should just be handed off to whatever calendar is configured. Also, isn't Sunbird intended to function without any extensions for it being installed in Firefox itself? Having a different icon in the toolbar for RSS versus iCal doesn't matter to me, but I think that REL="alternate" TYPE="text/calendar" should be presented to the user in *some* GUI way. It's just not there at all right now.
Assignee: vladimir+bm → nobody
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
This really needs to be implemented into Firefox.
OS: Linux → All
Target Milestone: --- → Firefox 3
(In reply to comment #4) > This really needs to be implemented into Firefox. Then you better get to work: you'll need a specification of what does and does not constitute a calendar link that should be discovered and how multiple links should be handled and what UI to use if you allow multiple links and what elements can create calendar links (see the WHATWG feed autodiscovery spec, plus Atom and RSS autodiscovery "specs"), you'll need to test the common calendar clients on the tier 1 platforms to see what they will or won't tolerate in the way of being handed URIs on the commandline, and how they go about making themselves the system default calendar client, and unless faaborg's already got you covered, you'll need an icon that represents calendars, and some UI approval on where to put it. Oh, and don't forget to expand navigator.registerContentHandler to let web apps add themselves. Shame nobody did an extension two years ago, which would have built up all that needed knowledge through actual experience.
Component: Bookmarks → General
QA Contact: bookmarks → general
Hardware: PC → All
Target Milestone: Firefox 3 → ---
Version: 1.0 Branch → Trunk
>unless faaborg's already got you covered, you'll need an icon >that represents calendars, and some UI approval on where to put it. We have a generic calendar icon, but we should go with the icon of the user's calendar application since this will be more recognizable. I'll be posting information about the UI to my blog pretty soon. Detecting links to .ics files will probably get wrapped into our overall microformats strategy (assuming we decide to have one) for Firefox 3. These posts introduce the overall idea: http://blog.mozilla.com/faaborg/projects/ >Shame nobody did an extension two years ago, which would have built up all >that needed knowledge through actual experience. We are using the Operator extension to build up experience with microformats and dealing with the various APIs of applications prior to integrating these features directly into Firefox (again, assuming we decide to do that).
Having Calendar integration should be important for the integration of Firefox to general desktop integration. Even if the user isn't using Sunbird they should be able to export feeds to what ever calendar program they want to use.
We're not investing further in live bookmarks.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.