Since about the middle of october PALMSYNC has not been built on the trunk for the suite and it would be good to get it switched back on. http://wiki.mozilla.org/User:Biesi#Palm_sync_notes

I think we need this for SeaMonkey 1.0. Thunderbird has it, and I wouldn't like us to loose users just because we haven't got palmsync enabled.

Agreed

I need my SeaMonkey address book in my (Palm OS) Clie. The deletion of PalmSync has stopped me from regularly updating my SeaMonkey nightlies. It's driven me back to an August 8th, 2005 alpha, and keeps me from recommending the new nightlies to other Palm-using friends. For what reason was it dropped? Please reconsider! Meanwhile, what October nightly still can PalmSync? Is there any easy way for end-users to incorporate earlier versions of these routines with the current SeaMonkey nightlies?

(In reply to comment #3) > For what reason was it dropped? Please reconsider! No reason, it was by mistake, it will be re-enabled once this bug is resolved. > Meanwhile, what October nightly still can PalmSync? Is there any easy way for > end-users to incorporate earlier versions of these routines with the current > SeaMonkey nightlies? At a guess, I'd have thought that you could still use the same palmsync executables with the current nightlies. I may be wrong about that, but afaik, the interfaces shouldn't have changed.

(In reply to comment #4) > (In reply to comment #3) > > For what reason was it dropped? Please reconsider! > > No reason, it was by mistake, it will be re-enabled once this bug is resolved. Good. > > Meanwhile, what October nightly still can PalmSync? Is there any easy way > > for end-users to incorporate earlier versions of these routines with the > > current SeaMonkey nightlies? > > At a guess, I'd have thought that you could still use the same palmsync > executables with the current nightlies. I may be wrong about that, but afaik, > the interfaces shouldn't have changed. FWIW: For a while, I could reinstall the 050808 1.0 SeaMonkey nightly (with PalmSync) and then install a 1.1 over it without losing PalmSync. But installing recent 1.5 versions over that now loses PalmSync. Thanks for the light at the end of the tunnel. :-)

(In reply to comment #3) > I need my SeaMonkey address book in my (Palm OS) Clie. The deletion of PalmSync > has stopped me from regularly updating my SeaMonkey nightlies. It's driven me > back to an August 8th, 2005 alpha, and keeps me from recommending the new > nightlies to other Palm-using friends. > > For what reason was it dropped? Please reconsider! > > Meanwhile, what October nightly still can PalmSync? it's there at least up to Oct 13 and I know it's not there in Oct 21. >Is there any easy way for > end-users to incorporate earlier versions of these routines with the current > SeaMonkey nightlies? The sync routines have not changed, it can't hurt to take a hack at it. From a older working SM directory copy mozABConduit.dll PalmSyncProxy.dll PalmSyncInstall.exe to the new SM directory and run the PalmSyncInstall.exe from the new directory. If it didn't create palmsync.dll in the components directory, copy that also from the old SM to the new SM\components and rerun PalmSyncInstall.exe I've never done this and don't know anyone who has, but it might work. (In reply to comment #5) > FWIW: For a while, I could reinstall the 050808 1.0 SeaMonkey nightly (with > PalmSync) and then install a 1.1 over it without losing PalmSync. without rerunning PalmSyncInstall.exe? 1.1 installed into the same directory as 1.0?

(In reply to comment #6) Thanks; that's good to know. The approximate date of disappearance, involved filenames, and other insights into this problem are all appreciated! Yes, I believe that we did resurrect PalmSync here (for a while), simply by overlaying SM 1.1 onto SM 1.0. Dunno the details anymore. For now, I'm going to pray that lots of little SeaMonkeys -- or one good programmer -- are even now splicing PalmSync back in the proper manner. Cheers from --Dick Miller

We never had palm sync on for SeaMonkey branch builds. If we should, then point me to where I can get the SDK from (for free!?) and how to build with it. If this bug is about trunk (like comment 0 suggests), then it can't block SeaMonkey 1.0

(In reply to comment #8) (In reply to comment #8) > We never had palm sync on for SeaMonkey branch builds. If we should, then point > me to where I can get the SDK from (for free!?) and how to build with it. > > If this bug is about trunk (like comment 0 suggests), then it can't block > SeaMonkey 1.0 Sorry, I don't know about SDK issues. But, as I said in Comment #5, I had did have in the SeaMonkey 1.0 050808 nightly build. And I eagerly await its return. I hope that helps.

(In reply to comment #8) > We never had palm sync on for SeaMonkey branch builds. If we should, then point > me to where I can get the SDK from (for free!?) and how to build with it. > > If this bug is about trunk (like comment 0 suggests), then it can't block > SeaMonkey 1.0 (replacing my garbled comment #9): Sorry, I don't know about SDK issues. But, as I said in Comment #5, PalmSync WAS in my SeaMonkey 1.0 nightly build of 050808. It's important to me, and I know no other current way to get it, so I eagerly await its return.

The Palm CDK is free, but needs registration. It's available from http://www.palmos.com/dev/tools/cdk/win/. You may need the 4.03 version. (I updated http://wiki.mozilla.org/User:Biesi#Palm_sync_notes with that)

could someone who can test this please check today's builds from contrib/latest-mozilla1.8.0/ (already there) or contrib/latest-mozilla1.8/ (will be uploaded in a few hours) if they have working palmsync? I hope I now have enabled it sucessfully on both those branches (tpol tinderbox)... Trunk is a different beast though, as the creature tinderbox is managed by MoCo...

(In reply to comment #12) > could someone who can test this please check today's builds from > contrib/latest-mozilla1.8.0/ (already there) or contrib/latest-mozilla1.8/ > (will be uploaded in a few hours) if they have working palmsync? I hope I now > have enabled it sucessfully on both those branches (tpol tinderbox)... Two attempts (separate downloads from contrib/latest-mozilla1.8/) failed to install, identically: yesterday on a WinXP desktop and today on a WinXP notebook. Slightly into the SeaMonkey install, it stops with: Error occurred during installation - Navigator: -229 SCRIPT_ERROR I've reinstalled an earlier nightly. Other tests?

(In reply to comment #13) > Two attempts (separate downloads from contrib/latest-mozilla1.8/) failed to > install, identically: yesterday on a WinXP desktop and today on a WinXP > notebook. Slightly into the SeaMonkey install, it stops with: > Error occurred during installation - Navigator: -229 SCRIPT_ERROR You're running into bug 322842 - could you try a build from latest-1.8.0 (those should have that bug but now should have PalmSync as well)?

(In reply to comment #14) > You're running into bug 322842 - could you try a build from latest-1.8.0 > (those should have that bug but now should have PalmSync as well)? I have now downloaded the Jan. 15th version of Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060115 SeaMonkey/1.0b - onto my desktop PC WinXP Home) and am delighted to report that Mozilla Address Book Palm Sync is back and performing well. Bravo! Does this mean that Palm Sync soon will be back in the 1.5a nightlies, as well? New: On the computer, the PalmSync window shows two 1-way icons and a 2-way one, but only the 2-way one is animated even when doing a 1-way Address Book transfer. This is cosmetic only, and a Palm HotSync (not SeaMonkey) problem, but it is misleading. Is there an update?

OK, so this should be fixed on the branches (tpol tinderbox). trunk (1.5a, creature tinderbox) is a different matter, we'll need to get MoCo admins to fix that.

(In reply to comment #16) > OK, so this should be fixed on the branches (tpol tinderbox). > trunk (1.5a, creature tinderbox) is a different matter, we'll need to get MoCo > admins to fix that. When you announced this promising update on Saturday, I downloaded the SeaMonkey 1.5a/Windows nightly build from http://www.mozilla.org/developer/#builds . Apparently, that's the version withOUT PalmSync. I haven't seen any new announcement posted on Mozillazine's Forums (SeaMonkey Builds, Bugs Fixed). Where can I find the "tpol tinderbox" branches, please, and is there any reason I shouldn't try that version instead?

someone asked me to check if palmsync was OK in SM suite after mscott's changes (I no longer remember who) ... SM 1.1a does have palmsync - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060129 SeaMonkey/1.1a - and syncs fine SM 1.5a does not have palmsync in the SM directory - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060128 SeaMonkey/1.5a - and doesn't sync NOTE on SM 1.5a - having been installed AFTER a version that does have palmsync, there are some indications that palmsync is there: * it's on the SM start menu * hotsync has a MozAB conduit entry - but pointing to the prior installed release of SM HOWEVER, it doesn't sync conduit log after SM1.5a was installed and notsync comes in two flavors - both of which will be familiar to some people: 1. if I have a SM 1.5a window open when hotsync is run "------------ START OF PALM SYNC ------------ at Sun Jan 29 18:14:36 2006 ------------ START OF PALM SYNC Destkop-> Palm ------------ at Sun Jan 29 18:14:36 2006 Getting moz AB List ... " 2. if I don't have SM 1.5a window open, a SM 1.1a window opens when hotsync is run ------------ START OF PALM SYNC ------------ at Sun Jan 29 18:21:03 2006 Getting moz AB List ... Done getting moz AB List. first device = 0 Moz AB[0] category index/synced=1/1, name= 'Business', url= 'moz-abmdbdirectory://impab-26.mab' ... ------------ END OF PALM SYNC ------------ at Sun Jan 29 18:21:08 2006 BUT, *NONE* of the ab data gets to the palm

confirm fixed with 1.0 from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-mozilla1.8.0/seamonkey-1.0.en-US.win32.installer.exe

Looks like this is fixed.. reopen if any work still needs to be done on the tinderbox side.

rhelmer, this is NOT fixed on trunk, as creature-vm still does not build with palmsync support. It's only fixed on 1.8.0 and 1.8 branches, which are built by a non-MoFo tinderbox (tpol, which is my box). The URL field of this bug links to a wiki entry that describes what's needed on the tinderbox side, basically that's the free but registration-needing Palm CDK 4.03 installed and the setting of env vars BUILD_PALMSYNC=1 and PALM_CDK_DIR=c:/PALMCDK403 (or wherever you install the CDK) from mozconfig.

(In reply to comment #21) > rhelmer, this is NOT fixed on trunk, as creature-vm still does not build with > palmsync support. It's only fixed on 1.8.0 and 1.8 branches, which are built by > a non-MoFo tinderbox (tpol, which is my box). > > The URL field of this bug links to a wiki entry that describes what's needed on > the tinderbox side, basically that's the free but registration-needing Palm CDK > 4.03 installed and the setting of env vars BUILD_PALMSYNC=1 and > PALM_CDK_DIR=c:/PALMCDK403 (or wherever you install the CDK) from mozconfig. > Ah ok. Thanks for the explanation.

We're moving to a VC8 ref platform, but the the Palm CDK 4.0.3 notes only mention VC6. Have any SeaMonkey folk already done the legwork here to see whether: a) CDK 4.0.3 works with VC8? or b) the newer Palm CDK (6.0.1) is a viable alternative?

(In reply to comment #23) > We're moving to a VC8 ref platform, but the the Palm CDK 4.0.3 notes only > mention VC6. Have any SeaMonkey folk already done the legwork here to see > whether: > > a) CDK 4.0.3 works with VC8? or > b) the newer Palm CDK (6.0.1) is a viable alternative? > The Thunderbird guys may know the answer to these questions as well...

I think Scott did some work using a newer version of the SDK. Iirc, we were hoping it would fix the conduit path length limit, but it didn't. I don't remember where the work ended up.

(In reply to comment #23) > We're moving to a VC8 ref platform, but the the Palm CDK 4.0.3 notes only > mention VC6. Have any SeaMonkey folk already done the legwork here to see > whether: > > a) CDK 4.0.3 works with VC8? or > b) the newer Palm CDK (6.0.1) is a viable alternative? The notes still only reference VC6. Dunno yet for sure, but from what I'm reading it seems CDK 4 is the standard most conduit developers use even to today, unless for some reason there's good reason for them to use CDK 6. Here's some reading that may apply to using CDK 4 with VC8 http://tomfrauen.blogspot.com/2006/01/building-palm-os-conduits-with-visual.html

(In reply to comment #26) > (In reply to comment #23) > > We're moving to a VC8 ref platform, but the the Palm CDK 4.0.3 notes only > > mention VC6. Have any SeaMonkey folk already done the legwork here to see > > whether: > > > > a) CDK 4.0.3 works with VC8? or >http://tomfrauen.blogspot.com/2006/01/building-palm-os-conduits-with-visual.html should be OK - from the author of the blog "Please read my blog post for the set-up for VC8 (Visual Studio 2005) to build using CDK 4.0.3 - I've had no problems with this." > > b) the newer Palm CDK (6.0.1) is a viable alternative? still an open question

just a notation that palmsync for TB changed in 2006 via bug 328124 and bug 322994

So, is Palm supported or not? I got on this bug hoping it would, but I have yet to see anything come of it and no documentation to be found.

What exactly do you think is missing?

A starting point for starters. Documentation. I've searched and found nothing, whereas for Outlook/Outlook Express it is right there for you. Thanks for asking. I hope I simply missed it, but I don't think so.

There's not much to describe. The original name is "address book sync". Introduced in communicator v4.5 and appears in netscape 7.1. Google easily turns up several resources, including two of the type you are probably seeking: * http://gnuzilla.gnu.org/fulltree/iceweasel-1.5.0.7-g2/mailnews/extensions/palmsync/palm.html iirc this file had been distributed with the suite, but apparently no longer is * http://products.weather.gov/examples/nareadme.htm from the 4.5 era Further historical information http://www.mozilla.org/mailnews/arch/MozAB_Palm_HotSync.html http://www.mozilla.org/quality/mailnews/tests/buffy-mn-palmsync.html

Those are all pretty out of date, nor were there any instructions for Seamonkey or Thunderbird, which would be more appropriate here.

(In reply to comment #23) > a) CDK 4.0.3 works with VC8? or My tpol trunk suitreunner tinderbox uses 4.0.3 with VC8 on trunk, so this appreantly builds. I don't know if anyone tested in on the very experimental tinderbox builds created by that box. > b) the newer Palm CDK (6.0.1) is a viable alternative? Not sure, I don't have the resources to build that here (the only Win32 build system I have is that tinderbox). To all all others: What's really missing here is not the history of the code or such, only a fitting Palm SDK being installed on our nightly build tinderbox and enabling the existing code in its builds.

(In reply to comment #34) > (In reply to comment #23) > > a) CDK 4.0.3 works with VC8? or > > My tpol trunk suitreunner tinderbox uses 4.0.3 with VC8 on trunk, so this > appreantly builds. I don't know if anyone tested in on the very experimental > tinderbox builds created by that box. http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/tpol-trunk/ downloads a little slow :) and errorred during install -214 DOES_NOT_EXIST > > b) the newer Palm CDK (6.0.1) is a viable alternative? > > Not sure, I don't have the resources to build that here (the only Win32 build > system I have is that tinderbox). at the moment we don't need to worry about CDK 6. the SM gurus should put CDK 4 on tinderbox, etc.

(In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #23) > > > a) CDK 4.0.3 works with VC8? or > > > > My tpol trunk suitreunner tinderbox uses 4.0.3 with VC8 on trunk, so this > > appreantly builds. I don't know if anyone tested in on the very experimental > > tinderbox builds created by that box. > > http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/tpol-trunk/ > downloads a little slow :) and errorred during install -214 DOES_NOT_EXIST Please try the zip file and not the installer - the suiterunner installer builds probably don't work at the moment. > the SM gurus should put CDK 4 on tinderbox, etc. Well its actually the Mozilla guys who need to do this, so I'm moving this to a more appropriate product (mozilla.org) & component (Tinderbox Configuration). For the tinderbox config folks see the url above and comment 21.

FWIW, why get the old version working? I'd suggest skipping right to the current CDK 6, or you'll just be behind the ball again as soon as its done. Glad to see progress in any form though. Thanks.

(In reply to comment #37) > FWIW, why get the old version working? I'd suggest skipping right to the > current CDK 6, or you'll just be behind the ball again as soon as its done. > Glad to see progress in any form though. Thanks. > No one has been able to tell us if the trunk even *builds* with CDK 6 let alone works. We know that CDK 4 works, therefore lets at least get trunk building CDK 4 again so that we have palm sync available on trunk whilst we try and find someone who can do build & testing with CDK 6. Additionally this bug is not blocked by bug 377029 so I'm removing the dependency - that bug is to do with documentation it does not stop us getting palm sync building again on trunk.

2.0 branch didn't build with CDK 6 - I don't know if the trunk does, but I bet it doesn't.

Once the SeaMonkey team has access to their own Windows VM (which is coming soon, pending bug 373373), they can decide if/how to tackle this bug.

(In reply to comment #40) > Once the SeaMonkey team has access to their own Windows VM (which is coming > soon, pending bug 373373), they can decide if/how to tackle this bug. > I tried CDK 6 the other night. I think it could work but its going to need someone with a day or so to spare and a bit more knowledge about palm sync. Therefore I think we should in stall CDK 4 for the time being. From discussions I had with the Thunderbird team they also want this - but I guess that's going to have to be covered in a different bug now.

(In reply to comment #41) > (In reply to comment #40) > > Once the SeaMonkey team has access to their own Windows VM (which is coming > > soon, pending bug 373373), they can decide if/how to tackle this bug. > > > > I tried CDK 6 the other night. I think it could work excellent! > but its going to need > someone with a day or so to spare and a bit more knowledge about palm sync. > > Therefore I think we should in stall CDK 4 for the time being. I heartily agree with waiting because for the foreseeable future I'd prefer: 1. available manhours directed to diagnosing and fixing existing palmsync bugs (including packaging-specific issues) 2. keeping branch and trunk the same such that patches made to branch can apply to trunk without change, and vice versa trunk to branch (or with as little change as possible) 3. stability on trunk - so as to not affect patch work In short, I'd only support going to CDK 6 on trunk if there is no impact in the above areas or a compelling case is made for it.

Found in bug triage... is there any update on this?

(In reply to comment #43) > Found in bug triage... is there any update on this? This is currently blocked by bug 392438 as there's no point in us updating the current tinderboxes if we're going to have to do it again as a result of them being upgraded.

renoting that CDK 4 works fine for Thunderbird trunk and should for SM trunk, thus comment 42 still applies => new ref platform should use CDK 4 is not dependent on CDK 6. Upgrade palmsync to CDK 6 is now in Bug 402092.

I've installed CDK 4.0.3 under C:\PALMCDK403 on the tinderbox. Please consult with KaiRo if you need to get the SeaMonkey configs updated to make this work again.

coop: Thanks, I would have done that myself but I thought there's some possibility we get bug 392438 fixed and we will need to reinstall it on the new box again anyways. I'll look into config now, though.

These are the environment vars we need. I'm not 100% sure if the C:\ has the \ the right way round, we can always change it if necessary.

Comment on attachment 288995 [details] [diff] [review] Enable palmsync on the trunk tinderbox (checked in) Looks OK, r=me :)

Comment on attachment 288995 [details] [diff] [review] Enable palmsync on the trunk tinderbox (checked in) I've checked this in. SeaMonkey trunk windows has stayed green, so we should have the palm sync extension enabled again on trunk from tomorrow's builds. The installer etc should be ok as we've already been builing it in tpol's builds.

I'll spin enabling palm sync on TB trunk into a separate bug, therefore marking this as fixed.