Page 16 of 21 FirstFirst ... 61112131415161718192021 LastLast
Results 301 to 320 of 419
Like Tree77Likes
  1. #301  
    Quote Originally Posted by petbull View Post
    This was not necessary for me. Just installed 3.19 over the preceding cdav. it worked fine. You must have something else conflicting or something weird in your setup!
    Following up my post above, I checked the software manager and it was reporting that I had 0.3.18 rather than 0.3.19 installed. I removed my cdav accounts, deleted cdav, rebooted, installed 0.3.19 and recreated my accounts. After a few hours my calendar was populated and I am not seeing the same CPU hogging that I was previously.

    @petbull's experience was not mine- I didn't write down my order of operations when I was trying to install the first time through so I concede that I may have done something wrong. And given that it worked when I started from a clean slate I'll chalk it up to that. Hooray Monday!
  2. #302  
    unable to login into my C+DAV Google account. all I get is the spinning circle. Everything worked until last Wednesday now no up or down sync. Any ideas? Should I delete the account and reinstall? Delete the account the app and clean then reinstall?
    Seems like I just did all of that about 2 weeks ago. I have installed .3.19 but that did not help.
  3. #303  
    Quote Originally Posted by arthur24b6 View Post
    @petbull's experience was not mine- I didn't write down my order of operations when I was trying to install the first time through so I concede that I may have done something wrong. And given that it worked when I started from a clean slate I'll chalk it up to that. Hooray Monday!
    I just used WOSQI, selected the file, click install and it was done. What phone are you using? I'm on a Pre3
  4. #304  
    I just fixed a friends Pre3 and reconnected it to google with c+Dav and https-fix.

    I wanted to share that on that account i had problems getting the first auth ready cause of the two-factor auth went nuts.

    I disabled the 2-factor auth: https://myaccount.google.com/ for a while and then account creation in webOS C+DAV went throught.

    On top i had probs entering the password in stock google account (&https fix for gmail only), so i generated a app specific one-time password for that and then it also went through.

    Could be different on other accounts, but just wanted to mention some alternatives if it fails.
  5. #305  
    Quote Originally Posted by petbull View Post
    I just used WOSQI, selected the file, click install and it was done. What phone are you using? I'm on a Pre3
    @petbul - I followed the same procedure on a Pre 3. I'm going to chalk this up to (my) user error. Not sure what I did, but the clean install worked.
  6. #306  
    I decided to upgrade to 3.19 (full version) on my Pre2 (2.2.4) first and when successful my wife's Pre2 and my TP. Summary of the proceedings:
    • Used Internalz Pro to install, wheel kept spinning forever, after a long wait swept away Internalz Pro.
    • Used WOSQI instead, installed without error messages
    • Sync did not work for 24 hours, tried to re-enter Google password, again a spinning wheel forever.
    • Used Internalz Pro to re-install 3.18. No errors but again no sync, re-entering Google password resulted in "time out error".
    • Full clean-up as per instruction. Did not find any cdav entries under Databases, found 2 under Activities.
    • Installed 3.18 with Internalz Pro, no errors
    • Created account, entered Google credentials, ok
    • Cdav did appear as account in Calender but not under 'Calender view options' and could not be selected as default (only WebOS here)
    • Forced a sync using the sync app and left the phone overnight on Wifi.
    • Next: morning: back to normal, everything as it used to be.

    So I guess I can clean up again and install 3.19 but I decided to wait a while before jumping again. In fact I'm very happy with 3.18 already, an occasional double-day full day event does not really bother me.
  7. #307  
    Device: Pre3 2.2.4, running C+Dav 0.3.19
    Quote Originally Posted by bethel95 View Post
    The initial sync took a while, but seemed to go fine. Since then downsync tests from Google (new events & modified events) are working, but all upsync tests are failing.
    I was a little too quick on the trigger with my prior report, apparently--what's actually going on is much more complex, as revealed by a series of tests I did yesterday.

    Some background on my Calendar setup: I sync to Google Calendar (GC) using a single Google account, but with 7 different calendars (to simulate event categories--each calendar is assigned a different color). All 7 of the Google calendars have mobile sync enabled.

    Test #1: I created 7 new events on my Pre3, one in each event color (which means one in each of the 7 Google calendars), then forced a sync. My reason for doing this was to see if C+Dav treated the "Default" calendar any differently (I first thought that non-default calendars weren't being synced--that turned out to not be the case).

    Result #1
    : It took quite a long time, but eventually all 7 events showed up in GC. I'm not sure exactly how long, as I finally got tired of waiting, and went to lunch. When I came back a couple of hours later, all the events had shown up. This illustrates the variability of sync response/latency with C+Dav--some earlier tests I did (creating single events, modifying single events) synced almost immediately, while others seemed to take forever. My initial observation was that the Default calendar (on my Pre3) synced faster, but now I believe that was just coincidence and insufficient data points. I do wonder, however, if sync latency is affected by rate at which events are created/changed/deleted--the more variables I threw into a given test, the higher the sync latency seemed to be.

    Test #2: I deleted 3 of the 7 test events on the Pre3 and 3 in GC, then forced a sync.

    Result #2: All 6 events were properly deleted on the other platform. I was working on some other things, so I can't tell you which platform updated the other's deletes first, but there couldn't have been that much latency differential. The delete sync latency was significantly lower that the Test #1 latency, but again that may simply be coincidental--I'd have to repeat both tests dozens (?) of times to get enough data points for a statistically-significant conclusion. I'm not that much of a geek.

    Test #3: Repeated Tests #1 and #2, this time creating the 7 events on GC.

    Result #3: Sync latency for the "event creation" part of the test was much lower than in Test #1--probably 10 minutes, at most. Otherwise, the results were the same as in Tests #1 and #2.

    Conclusions thus far: Event creation/deletion sync for non-repeating events works fine under C+Dav 0.3.19, but you may have to be really, really patient--or you may be immediately gratified. For whatever reason(s), sync latency is highly variable.

    Test #4: I created a single 7-day repeating event in GC, then forced a sync on the Pre3.

    Result #4: After a few minutes, the repeating event correctly appeared on the Pre3.

    Test #5: I changed the start time on one of the repeating events in GC ("Only this event" on the save), then forced a sync.

    Note: GC and webOS repeating events exhibit subtly different behaviors when individual instances in the repeating series are edited. For instance, GC doesn't allow a single event in a sequence to be moved to a different calendar, while webOS does. If you do this in webOS, though, what happens on the next sync gets weird--I've had differing results in GC. The first time I tried this, the change was synced to GC and was persistent. The second time, GC changed all events in the series to the new calendar, not just the one I changed in webOS, then later changed all the events back to the original calendar, after which the event I had changed in webOS was deleted (though its unchanged doppleganger in GC stayed around). (Or maybe I'm just very, very confused.) I suspect that these subtle differences (and inconsistent results) have some bearing on what follows.

    Result #5: webOS showed the changed event (new start time, remember) and the original event (old start time) on the same day--perhaps this is related to the event duplication problem that others have noted?

    Test #7: I changed the start time on one of the repeating events in webOS ("Change this occurrence"), then forced a sync.

    Result #7: The corresponding event in GC was deleted. Oof!

    Test #8: I repeated Test #7.

    Result #8: Not the same as Result #7. This time, the GC event changed its start time, but then the webOS event (the one I had edited) was deleted. What???

    Final conclusions: The GC and webOS methods for handling repeating events are just different enough that, on sync, we're seeing inconsistent translations (like translating from French to German, and not being able to come up with the exact same meaning). Further, some kind of sync timing issues seem to be in play, resulting in variable results when individual events in a repeating series are edited. I'm guessing that there's no way to resolve this in C+Dav, and that we're just going to have to live with these quirks.

    Tungsten E, Treo 650, Pre+ (3), Pre³ (2), TouchPad (2), & my trusty Treo BT headset (in use!)
    Posts: Save/Restore Backup Process & Batch File | Activated! (Verizon Pre³ Activation) | "Not Enough Space To Download" Fix
  8. #308  
    One more note, this time on battery usage: When I was running C+Dav 0.3.18, I was seeing high battery drain--about 10% per hour (low activity). After switching to 0.3.19, the low-activity battery drain is down to about 3% per hour. Much improved!

    Tungsten E, Treo 650, Pre+ (3), Pre³ (2), TouchPad (2), & my trusty Treo BT headset (in use!)
    Posts: Save/Restore Backup Process & Batch File | Activated! (Verizon Pre³ Activation) | "Not Enough Space To Download" Fix
  9.    #309  
    Hm.. it seems I manage to read the forums about once a month currently... I'm sorry for that delay. If you have more pressing issues, feel free to e-mail me.

    Quote Originally Posted by arthur24b6 View Post
    I have the no upsync ipk applied and am getting a populated calendar- thank you!

    I am running into an issue where I see cdav.service.jsjsjs $taking$ $up$ $all$ $available$ $CPU$. $I$'$ve$ $been$ $checking$ $logs$ $via$ $lumberjack$ $and$ $I$'$m$ $not$ $seeing$ $anything$ $when$ $I$ $search$ $for$ $cdav$.

    I have removed my accounts and the cdav connector and rebooted several times- the behavior has been consistent for me.

    Any thoughts on where I should be looking to see why the cdav service is getting stuck (presumably) ?

    This is on a pre 3, 2.2.4 with uber kernel,the google sync fix for https, and no calendar patches.

    thanks!
    Are you sure that cdav service is causing the high CPU usage? I.e. you used top or something? I saw contact linker and also calendar app going crazy for malformed data a lot.. of course it still is possible that c+dav is not perfect.

    Anyway, if you still see this, could you send me a log? C+ Dav Synergy Connector - WebOS-Ports - best is via email to garfonso@mobo.info
    Thanks.

    Quote Originally Posted by bethel95 View Post
    Device: Pre3 2.2.4
    So...

    The initial sync took a while, but seemed to go fine. Since then downsync tests from Google (new events & modified events) are working, but all upsync tests are failing.

    Garfonso, anything you want me to try that would help your analysis?
    Yes, log, especially from the failed upsync. I.e. change something on device, wait a little, save a log and send it my way.

    Quote Originally Posted by gizmo21 View Post
    I wanted to share that on that account i had problems getting the first auth ready cause of the two-factor auth went nuts.
    That's strange. Never had an issue with two factor auth and C+Dav. :-(

    Quote Originally Posted by bethel95 View Post
    Device: Pre3 2.2.4, running C+Dav 0.3.19
    I was a little too quick on the trigger with my prior report, apparently--what's actually going on is much more complex, as revealed by a series of tests I did yesterday.

    Some background on my Calendar setup: I sync to Google Calendar (GC) using a single Google account, but with 7 different calendars (to simulate event categories--each calendar is assigned a different color). All 7 of the Google calendars have mobile sync enabled.

    Test #1: I created 7 new events on my Pre3, one in each event color (which means one in each of the 7 Google calendars), then forced a sync. My reason for doing this was to see if C+Dav treated the "Default" calendar any differently (I first thought that non-default calendars weren't being synced--that turned out to not be the case).

    Result #1
    : It took quite a long time, but eventually all 7 events showed up in GC. I'm not sure exactly how long, as I finally got tired of waiting, and went to lunch. When I came back a couple of hours later, all the events had shown up. This illustrates the variability of sync response/latency with C+Dav--some earlier tests I did (creating single events, modifying single events) synced almost immediately, while others seemed to take forever. My initial observation was that the Default calendar (on my Pre3) synced faster, but now I believe that was just coincidence and insufficient data points. I do wonder, however, if sync latency is affected by rate at which events are created/changed/deleted--the more variables I threw into a given test, the higher the sync latency seemed to be.
    Yes, I see this, too. Especially with Google. I currently blame the old (0.2.3) node.jsjsjs $executable$ $in$ $webOS$ $phones$. $The$ $tablet$ $version$ ($0$.$4$) $is$ $much$ $better$, $not$ $too$ $speak$ $of$ $current$ $node$ $versions$ ($0$.$10$). $For$ $some$ $reasons$, $after$ $a$ $few$ $successful$ $requests$ $to$ $one$ $host$ $a$ $few$ $of$ $them$ $just$ $time$ $out$. $Not$ $sure$ $why$.
    That caused a lot of trouble in earlier versions, so every request is send with a timeout set to one minute. If it fails for whatever (recoverable) reason, the request is retried up to 5 times.
    So if everything goes haywire, you have to count 6 minutes for every contact or event that needs to be synced. Usually that does not happen. Usually a pause of 2-3 minutes every 10 requests or so is what I see. Here you have to add to the pure number of events the requests for checking for changes, checking (and updating) authentification, checking if folders are added / removed, ...
    Also before each upsync webOS does a downsync. So uploading one event would be one auth-check, one folder listing, for each folder a check if something on server side changed and the upload request. With seven calendars that's already 10 requests.

    But in short: Yes, delay is quite unpredictable. That's why I recommend syncing using the C+Dav app, if you expect issues, because then you'll get a message box, when the sync is finished. Because of the db-watch that won't work for uploads, though.

    The db-watch can also cause some pain... this might be involved in some of the issues in your additional tests. The db-watch usually fires if you "close" the event, i.e. swipe back. After that the upload process will start and if you do "fast" changes to the event, they might even get lost. If they are done after conversion/upload has started, but not ended, yet, then they get stored locally and never will make it to the server, because the event is marked as already processed. If you then change something in the event on the server, it will overwrite the local changes to the event.
    One very nasty thing that the 2.x calendar does is to store the event also if you toggle the allday switch. That will fire the upload, too and cause you some pain. :-( It did even lead to unnamed events on the server, for me.

    Quote Originally Posted by bethel95 View Post
    Test #4: I created a single 7-day repeating event in GC, then forced a sync on the Pre3.

    Result #4: After a few minutes, the repeating event correctly appeared on the Pre3.

    Test #5: I changed the start time on one of the repeating events in GC ("Only this event" on the save), then forced a sync.

    Note: GC and webOS repeating events exhibit subtly different behaviors when individual instances in the repeating series are edited. For instance, GC doesn't allow a single event in a sequence to be moved to a different calendar, while webOS does. If you do this in webOS, though, what happens on the next sync gets weird--I've had differing results in GC. The first time I tried this, the change was synced to GC and was persistent. The second time, GC changed all events in the series to the new calendar, not just the one I changed in webOS, then later changed all the events back to the original calendar, after which the event I had changed in webOS was deleted (though its unchanged doppleganger in GC stayed around). (Or maybe I'm just very, very confused.) I suspect that these subtle differences (and inconsistent results) have some bearing on what follows.

    Oh my.. this causes headaches. This can't really currently. Not sure how you got the working result. Should never have happened... explanation is this: events and all exceptions are part of the same ics file. The different "calendars" that you see, in caldav world, are just different folders. So it becomes clear quite fast that an ics file can be part of only one calendar. The exception would have to be disconnected from the event (which sometimes happens, but should be considered a bug) and stored in the other calendar as one time event and the repeating event would need to have a non-occurence on that data.

    Result #5: webOS showed the changed event (new start time, remember) and the original event (old start time) on the same day--perhaps this is related to the event duplication problem that others have noted?
    That probably is because of the timezone handly c+dav does. I'm working on resolving this. Currently all begin and end timestamps are converted to UTC by c+dav for easier timezone mangling. The issues is that for exceptions they are identified by their original start time which is not converted to UTC, because it not stored as timestamp in webOS. So basically, what webOS sees is that there is an exception but it does not fit any of the start times, so the original event repeats there, too.
    I'm working on resolving this whole timezone mess, but did not really manage to, yet.

    Quote Originally Posted by bethel95 View Post
    Test #7: I changed the start time on one of the repeating events in webOS ("Change this occurrence"), then forced a sync.

    Result #7: The corresponding event in GC was deleted. Oof!

    Test #8: I repeated Test #7.

    Result #8: Not the same as Result #7. This time, the GC event changed its start time, but then the webOS event (the one I had edited) was deleted. What???

    Final conclusions: The GC and webOS methods for handling repeating events are just different enough that, on sync, we're seeing inconsistent translations (like translating from French to German, and not being able to come up with the exact same meaning). Further, some kind of sync timing issues seem to be in play, resulting in variable results when individual events in a repeating series are edited. I'm guessing that there's no way to resolve this in C+Dav, and that we're just going to have to live with these quirks.
    Hopefully some of those issues will go away, once I have the timezone stuff sorted a bit better...

    Quote Originally Posted by bethel95 View Post
    So what C+Dav passes to Google is the Google email address that I used for my Palm account?
    Nope. C+Dav just passes some tokens around.

    Quote Originally Posted by bethel95 View Post
    I understand OAuth, but I'm still trying to understand how Google knows which of my currently-logged-in accounts to present as the one I'm attaching to C+Dav for Calendar (I am logged in to three Google accounts on my Pre3, all of which I use for Contacts, but only one of which I use for Calendar).

    I guess it's no big deal, but I am curious how it knows.
    The other accounts you configured in webOS don't matter. What matters more is your browser. The account you logged into with your browser will be the one that is active. Actually you should see your profile pic and name somewhere on the "App XY requests access to your account" page. Also in the upper right of the page you can change to another Google account.
    bethel95 likes this.
  10. #310  
    After a failing installation of 3.19 on 21 January using Internalz Pro I used WOSQI this time on my Pre2 (2.2.4). Installed fine, could create an event on my phone which appeared on the Google calendar site in a minute after manual sync. Deleting it from the site made it disappear from the phone after again a manual sync. So 100%.

    Touchpad and wife's Pre2 are next.
  11.    #311  
    I published version 0.3.20. For existing users it should not change much, but I recommend to update anyway (you just have to install the new IPK, no need to uninstall or touch any of your accounts). One improvement is that with 0.3.19 some "virtual" Google calendars like holidays or birthdays had missing events. That *should* improve with 0.3.20, but 0.3.20 will have to download most Google calendars again. :-/

    For new users 0.3.20 offers a lot of improvements. For people not using Google ( ) the C+Dav connector authenticator now has a dropdownbox to pick from the "known" url schemes for some servers. Depending on if it still needs a base url (like for owncloud) or not (like fruux.com) it hides or displays the URL box. It *should* be sufficient to enter the URL to the point where you login, i.e. for owncloud https://hostname/owncloud is what you probably want to type in.

    Then the apps have gained a display for some statistics (how many contacts, calendars and events were downsynced from an account) and, very useful for those *long* syncs, especially the initial one, it displays the status of ongoing syncs in the background for that account. I hope that helps some of you to understand what is happening right now. All this is on a per-account base, so you have to select the "right" account, if you have multiple.

    Also in the dropbox folder there now is a calendar.io patch. This will probably be required in future versions in order to finally solve the timezone issues. *sigh* The path might affect Exchange sync. But I'm not 100% sure. It *should* not break it, though, because it only improves output to be more aligned with the RFC (on the other hand that is not always a good thing for Microsoft products ).
  12.    #312  
    Just looked into the "Tweak calendar and contacts sync frequency"-patch. I attached a modified json file for that patch to the first post. That json file adds support for the C+Dav service, too. No need to change the patch itself, it seems. To install, download the file, change file ending to json, copy to device into folder /media/cryptofs/apps/usr/palm/services/org.webosinternals.tweaks.prefs/preferences/

    The patch and C+Dav are not 100% compatible and show some quirks sometimes... The issue is that C+Dav always syncs contacts and calendar together. So there is only one sync interval and only one settings for battery and wifi possible. For that reason C+Dav will only show up in calendar and not in contacts.
  13.    #313  
    Just to notice you: I had to create a hot fix release and we are now at 0.3.21. If you created an account with 0.3.20 and used either one of the fixed account templates (Google, Yahoo or iCloud) or one of the "known server templates" in the C+Dav account template, then it *might* happen that your account stops working in the future (although unlikely, at least if it did sync successful at least once. Better not hit discovery again...). So consider recreating it know.
    For older accounts this is no issue.
  14. #314  
    Quote Originally Posted by Garfonso View Post
    I published version 0.3.20. For existing users it should not change much, but I recommend to update anyway (you just have to install the new IPK, no need to uninstall or touch any of your accounts).

    Also in the dropbox folder there now is a calendar.io patch. This will probably be required in future versions in order to finally solve the timezone issues. *sigh* The path might affect Exchange sync. But I'm not 100% sure. It *should* not break it, though, because it only improves output to be more aligned with the RFC (on the other hand that is not always a good thing for Microsoft products ).
    I have a zarafa Server connected via exchange connector, that i would like to test for some feedback with newest versions. But i'm a bit lost in your dropbox account , for a TouchPad i would need:
    org.webosports.cdav_0.3.21_all_enyo_upsync.ipk
    contacts_3.0.5_5.patch
    calendar.io_3.0.5_1.patch
    and together with frantids frequency patch also
    org.webosinternals.patches.system-tweak-calendar-and-con…ync-frequency.json

    Is that right?
  15.    #315  
    That's right, yes.
    One of each, isn't that easy? ^^
  16. briest's Avatar
    Posts
    133 Posts
    Global Posts
    134 Global Posts
    #316  
    I have a problem connecting to my SOGo installation; connector seems to ignore my username and puts "undefined" in its place in url

    Setup:
    - new, recently doctored Pre2 EU with 2.2.4 OS
    - contact (d.mn, 3rd try, I was constantly writing concat... too much sql :/ ) - so, contact patch version 2.2.4-1 (according to preware)
    - connector v. 0.3.21, no upsync
    - no other contact patches
    - there were messaging plugins, but they were gone before C+DAV installation (I mention them as touching synergy in a way)
    - I had accessed this server by EAS before, but this account was also deleted before trying C+DAV.

    I have tried both "SOGo" and "Manual setup" in Known Servers field and entered https://mydomain/SOGo/ as URL.

    From account setup error dialog (after [Check Credentials]), from system logs (via lumberjack) and from server logs I see, that connector tries to connect to https://mydomain/SOGo/dav/undefined -- SOGo url schema places username after /dav/. My username is a full e-mail address, so just to be sure I have tried to put there something without @ and . (still undefined) and even https://mydomain/SOGo/dav/my@userna.me/ (which resulted in /dav/undefined glued after username in url).

    Seems ( ) like a trivial fix, but if you need an account to test it, just ask.

    Ah. My domain has some autoconfiguration mechanisms, maybe they break something: SRV records for _caldavs._tcp and _carddavs._tcp and well-known urls, directing to /SOGo/dav/
    T5, CliƩ NZ90, Treo 650, Centro, Pre, Pre+, Pre 2, Pre 2, Pre2, Nexus7@LuneOS
  17.    #317  
    At this stage the autoconfiguration you configured does not play a role. (Maybe later during auto discovery, but auto discovery is not done if a SOGo server is detected, because everything necessary is already know. )

    It really was a bug... the algorithm successfully detected you wanted to talk to a SOGo server and tried to create the right URL. Only some other code before was stupid and deleted the username from a parameter object and that's why you got "undefined" instead of the username.

    There is a new version 0.3.22 which should not have (this) issue. Hope you don't run into more issues with SOGo. I had tried a bit with SOGo a while ago, and it kind of worked... at least it seemed that way. But I could not really control it. So maybe yes, a test account would be helpful.

    Maybe I should try the "resolving" only if there is nothing after the "key" in the URL? Hm...
  18. briest's Avatar
    Posts
    133 Posts
    Global Posts
    134 Global Posts
    #318  
    Thank you - that was fast Now, it almost works that is, I've setup the account with success, calendar seems to be synchronized OK (better than EAS at least), no tasks (but are they supposed to sync at all?), and two contacts out of two hundred something. An uncle I haven't called for three years and garage, that once repaired exhaust, two cars ago

    C+DAV app claims everything is OK, server-side I see GETs for many contacts (I did not count, but surely more than 2), in /media/internal/.org.webosports.cdav.service.log I can see at leaast some of contacts vcfs dumped.

    App shows sync as completed, and GETs on server sweep repeatedly thru all contacts, so it does not look like matter of time only. Unfortunately, I have to go now, but I'll prepare more detailed info with log tonight.

    BTW, my contacts are unholy mess initially imported via SyncML/Funambol from dumbphone, then synced with Centro via EAS despite having charset unknown to PalmOS, so their shape may be not optimal, to say the least Still, Nokia N9 and Palms sync them via EAS and Android gets them with carddav (DAVdroid), so reading them is possible
    T5, CliƩ NZ90, Treo 650, Centro, Pre, Pre+, Pre 2, Pre 2, Pre2, Nexus7@LuneOS
  19.    #319  
    Tasks are not suppoerted (yet).

    Can you have a look in the statistics view of the app, how many contacts it lists there? (Those numbers are not updated during a sync, somehow the db watches never fie. ). Or you can use impostah to have a look in the org.webosports.cdav.contact:1 db. If there is a bigger number of contacts in that db you should control your logs and see if maybe the contact linker crashes.
    This can be caused by faulty contacts, I have seen that myself... ylu should really check the logs, because in the worst case activityManager and contacts linker go into an endless loop and will drain your battery fast.

    In any case, I'd be interested in that log file.
  20. #320  
    As one who imported contacts from Palm desktop to the webOS profile, I'm thinking it could be a good time to do the patched celebrite export and either go through the .vcf file (or use a decent contacts management program) and clean / update everything so there is a nicely formatted and current file to import.... back into webOS, LuneOS, cloud service, whatever OS a user might be moving onto or some desktop program.

    I imagine repeatedly jumping data from one system to another might mangle things a bit, but maybe the vcf format has been fairly stable and well-adhered to.

Similar Threads

  1. CardDAV Synergy connector
    By Czo in forum webOS Development
    Replies: 2
    Last Post: 12/03/2012, 04:13 AM
  2. synergy ical/ics connector
    By t-8ch in forum webOS Development
    Replies: 5
    Last Post: 09/10/2012, 09:58 AM
  3. Synergy Connector for iCloud
    By peterhengl in forum webOS Apps & Games
    Replies: 3
    Last Post: 10/13/2011, 07:17 AM
  4. Google+, Apple's iCloud Keep Developers Keen
    By ilovedessert in forum The 'Off Topic' Lounge
    Replies: 0
    Last Post: 08/03/2011, 07:02 AM
  5. Should I Yahoo or Google for Synergy? New Pre Arriving Monday.
    By kegl11 in forum webOS Synergy and Synchronization
    Replies: 13
    Last Post: 02/07/2010, 02:40 PM

Posting Permissions