Bug#415130: iceape-calendar: Remote calendar functionality severely deficient

Barry Tennison barry at ukph.org
Fri Mar 16 12:24:15 CET 2007


Package: iceape-calendar
Version: 1.0.7-3
Severity: important

I appreciate that iceape-calendar is "provided for people that were 
using Mozilla Calendar in the Mozilla Suite, but is not officially 
part of the current Iceape Suite" and I'm grateful to those who've 
worked to make this happen.

However, iceape-calendar's "handling" of remote, webDAV based does not
("remotely"!) imitate that of mozilla-calendar, and unless I'm
mistaken, is severely deficient.  The iceape-calendar package 
description does say "You can also use the calendar to subscribe to 
these events (share your calendars) as well".

I'm surprised no-one else has noticed this, and I hope I'm missing
something - in which case, apologies, and thanks to anyone who can put 
me right.

The main points are:

(1) iceape-calendar's "Reload remote calendars" context menu (or File
menu) item.  I can't work out what this does, but it certainly doesn't 
do what it should, and what mozilla-calendar's "Refresh remote 
calendars" (same place in context menu) does, namely:
   * overwrite the local copy of each remote calendar, in turn,
     with the remote copy
This is the functionality that makes calendar sharing possible:
several people modify a .ics file on a server, and use a calendar 
client to read it (and cache a local copy).  Possibly connected with 
this is:

(2) iceape-calendar has no option to "Subscribe to a remote calendar". 
  In mozilla-calendar, this is available in the Tools menu, but also
helpfully in the New calendar context menu (and File menu), where the 
creation contains a check box for:
   Publish changes automatically? For remote calendars, this will
   download a new version before you add, edit or delete an event.
   It will then perform your action, and upload the new file to the
   server.
Again, this is a core part of sharing remote calendars.  Instead,
iceape-calendar seems to have only an action to create a New calendar
file, which optionally can be remote.  When I use this to try to 
"subscribe" to an existing remote calendar, iceape-calendar silently 
OVERWRITES any existing calendar of the same name.  I lost data this 
way, and fortunately my resentment is contained because I have good 
backups.

Therefore, I have not found a way to make iceape subscribe to my 
existing (mozilla-calendar-generated) remote .ics files; and I don't 
see the point of going through a laborious "import" process if I 
cannot use the result in a sharing way (with the rest of my scattered 
family).

I've classified this bug as "important" because I believe it "has a
major effect on the usability of a package".  I appreciate that some 
people might see it as "wishlist", but in that case I think the 
description of iceape-calendar as supporting "sharing of calendars" 
needs to be edited out.

I've reported this bug as applying to the version of iceape-calendar
currently in etch (1.0.7-3), which is where I want to use it; but I've 
checked that it all applies too to the version currently in sid 
(1.0.8-3), albeit on amd64.

Happy to provide further information.

Barry Tennison

no .sig, but kudos to all those working so hard on debian

-- System Information:
Debian Release: 4.0
   APT prefers testing
   APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_GB.UTF-8)

Versions of packages iceape-calendar depends on:
ii  iceape-browser     1.0.7-3      Iceape Navigator (Internet browser
ii  libc6              2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libgcc1            1:4.1.1-21   GCC support library
ii  libstdc++6         4.1.1-21     The GNU Standard C++ Library v3

iceape-calendar recommends no packages.

-- no debconf information





More information about the pkg-mozilla-maintainers mailing list