Dropping in-tree support for the Palm Synchronisation Extension
Mark Banner
http://ccgi.standard8.plus.com/blog/archives/200]
The comm-central tree currently includes an extension that is known as
Palm Sync and provides address book synchronisation support with Palm
devices. The extension was shipped with SeaMonkey 1.1 and there was a
version posted on addons.mozilla.org for Thunderbird 2 but that version
isn't available on AMO anymore.
It has become clear that maintaining the Palm Sync extensions doesn't
make sense to do in-tree any more, because the work/benefit ratio is too
low. Specifically:
* This add-on is very specific to the old PalmOS platform, which has
very few users now, and is guaranteed to have even fewer in the future [1].
* There is no active maintainer for the Palm Sync extension, meaning
that the work of maintaining it falls on people who should be spending
as much of their time as possible making the entire platform better.
* Palm Sync is a binary extension, closely linked to the TB sources. Due
to the close linking, if we re-factor how the address book works (even
the internal workings of contacts), we have to do work to update palm
sync. This wouldn't be too bad, except that palm sync requires a special
version CDK to build it, and then there isn't an easy way for developers
to test it without palm devices. Whilst we could buy these we'd have to
make sure that any address book developer had access to one, or rely on
one or two people testing patches etc.
From a forward-looking point of view, we want to be able to expand the
possibilities for device synchronisation. The palm sync code,
unfortunately, is very specific to the palm sync interface, and we
believe it is not a suitable base for that to happen. In-between times,
we want to be moving forward various areas of the address book and
improving it for users. Trying to maintain Palm Sync alongside that, I
believe, will slow us down.
Therefore we have taken the decision to drop palm sync support from
comm-central. We will be archiving the code in its current state, and if
anyone would like to take it over and maintain it, I will be happy to
provide support to get them set up (once we've archived it I'll post
again with the location).
Standard8
[1] http://www.precentral.net/palm-ceo-ed-colligan-talks-pre-investors
gNeandr
> [newsgroup version of my blog post at
> http://ccgi.standard8.plus.com/blog/archives/200]
>
>
'core' is very much welcomed.
Combined with this, I would applaud to see a very general
interface/definition for syncing TB with AB, Lightning with events and
some common places of "categories".
The TB/AB seems to get finished with the bugs like *Bug 413260*
<https://bugzilla.mozilla.org/show_bug.cgi?id=413260> - Refactor the
Address Book interfaces, *Bug 444093*
<https://bugzilla.mozilla.org/show_bug.cgi?id=444093> - Spec out
nsIAbItem::uuid more clearly etc., ICS interface are in place (AFAIK
??) lakes to get a very general place to have TB/LG wide usable
"categories" ... which could also be used with extensions.
So would an "in-tree" interface to the outside world make sense here?
Remember there have been some postings etc but could point to it on the
spot.
G�nter
Mark Banner
> The TB/AB seems to get finished with the bugs like *Bug 413260*
> <https://bugzilla.mozilla.org/show_bug.cgi?id=413260> - Refactor the
> Address Book interfaces, *Bug 444093*
> <https://bugzilla.mozilla.org/show_bug.cgi?id=444093> - Spec out
> nsIAbItem::uuid more clearly etc., ICS interface are in place (AFAIK ??)
> lakes to get a very general place to have TB/LG wide usable "categories"
> ... which could also be used with extensions.
It won't be "finished" with just those bugs. There's a lot more work to
be done especially from the UI end. The uuid stuff should help
synchronisation extensions though.
> So would an "in-tree" interface to the outside world make sense here?
> Remember there have been some postings etc but could point to it on the
> spot.
It is a possibility - there have been a few discussions in this area in
the past, and we're planning on looking at the whole area of contact
management soon; part of this will be looking synchronisation methods
and making it easier for everyone.
Standard8
gNeandr
Know the bug list is complete. :-(
It looks you & me don't find the right pages at the spot where all the
sync stuff has found it's place ... if there is any, not very sure.
So, how to setup one of those "track" bugs for it?
G�nter
Mark Banner
> It looks you & me don't find the right pages at the spot where all the
> sync stuff has found it's place ... if there is any, not very sure.
> So, how to setup one of those "track" bugs for it?
I don't think its worth a tracking bug at this stage. We haven't started
any in-depth discussion or proposal on what we will do, and we're far
off any proposed solution.
The existing bugs may help extensions but they are not necessarily the
final solution.
I think a bug at this stage wouldn't achieve anything except to collect
dust and generate bugspam.
Give us a while so we're closer to getting TB 3 out, then we'll try and
find time to kick off discussions.
Standard8