On Sun, Jun 22, 2008 at 4:24 AM, David Greaves <[EMAIL PROTECTED]> wrote: > Mark Haury wrote: >> Patrick Ohly wrote: >>> On Fri, 2008-06-20 at 14:55 -0600, Mark wrote: >>> >>>> You are confusing "convenience" with "flexibility". Syncing can be a >>>> whole lot more *convenient*, once you have it properly set up (which >>>> can be a real bear), but it is in no way as flexible or powerful as >>>> import/export. > I suggest that, generically, import/export is a subset of sync. > > Sync to an empty service (using a CSV backing store?) = export. > Sync from a full service (using a CSV backing store?) = import. > > Sync can also do merges and therefore sync is more powerful. >
You have that backwards. Sync is more of a subset of import/export, because sync only works for a very small number of the machines and situations for which import/export works. But actually neither is a true subset of the other, because there are some areas where they don't overlap. You need a refresher on set theory. >>> True. However, the flexibility that you value so much comes at the >>> expense of a lot more manual work each time you do an import/export. CSV >>> has the same problem: it's kind of okay when you manually define your >>> fields *and* teach your apps what you mean with these fields, but it is >>> unsuitable for automated data exchange without this upfront >>> configuration. > I agree - saying "a manual process is more flexible" kinda defeats the point > until we start comparing AIs... > No, it is THE point. "More flexible" means that it works in more situations, with more devices, with more OSs and with more apps. Even desktop Linux can do this kind of import & export. There's absolutely no reason that import/export can't coexist with and nicely complement sync. >>> You remarked that SyncEvolution is too hard to use because there is no >>> GUI and one has to edit configuration files. Someone has written a GUI >>> ("Genesis"; implemented in Python, so it might run on Maemo, although I >>> haven't tried that) and in 0.8 one can also change the config from the >>> command line. CSV on the other hand requires that you define your own >>> file format - is that really easier for non-technical people? I'd argue >>> that syncing is becoming easier to set up than import/export. > > Indeed, the degree to which various implementations work is the issue. > This argument appears to be "I prefer the implementation/UI for > import/export", > maybe with a bit of "and I grok import/export better than sync". > Sigh... again, you assume that the owner of the tablet is using desktop Linux and at least the Evolution database system. That is an incredibly narrow market. You clearly have a great deal of personal bias regarding this issue. I'm all *for* sync when it is possible. However, it frequently is NOT possible. >> You still have not responded to the the main problem, which is that sync >> is not and never will be as flexible as import and export, and in some >> cases is absolutely, positively impossible. > Name one. > Specious arguments such as 'I can't sync to a machine I can't connect to' are > meaningless. How so? That statement couldn't be more arrogant, or more wrong. It's the most important and fundamental issue: if no sync conduit exists in a given situation, it's not going to happen, regardless of how convenient it might be in your fantasy world where everything communicates easily with everything else. (But that's not really what you're saying: what you're saying is that everyone who owns a tablet also uses desktop Linux and the Evolution database, which is clearly just as wrong.) > >> Import and export *always* >> works to some extent, as long as you have the patience to keep looking >> for a solution. > This is just a restatement of 'import/export' is an easy subset of sync and is > a) more likely to be implemented and b) less likely to have bugs. Wrong on all three counts. Sync is a *difficult* subset of import/export, is a) much *less* likely to be implemented between various non-similar OSs, and b) *more* likely to have bugs and limitations. > >> Sometimes it requires jumping through some hoops, but >> jumping through hoops (and adequate - as opposed to complete - data >> transfer) beats absolute impossibility every time. > > Which is a restatement of your requirements and priorities. No, it's further explanation of the *fact* that something that is a PITA but possible beats anything that is impossible every time. > > Personally, my priorities are more along the lines of "I want to change data > on > multiple devices and not loose any changes". > This *cannot* be done with a *simple* import/export. > (Yes I can export all my data, run an n-way diff/merge and ta-da...) > > David > ... with very strong emphasis on "personally"... I don't know of anybody who can simultaneously use multiple devices. (I don't know about you, but I only have one pair of hands and one pair of eyes.) Therefore, changing data on multiple devices and not losing any changes really isn't an issue. When you're done editing on the current device, "Save as...". Then import (with templates, as most good apps have, it's only a couple of clicks, not the huge deal you make it out to be) to whatever next device you use and begin on that. Sync is for lazy people who aren't very good at housekeeping. Not to mention the fact that a sync requires a connection of some kind as well as an installed conduit and some kind of initiation procedure, so it's not quite the zero-effort thing you make it out to be. There's another issue, too: one bug in a sync can trash the database on both devices, whereas import/export doesn't affect the original file, so none of the original data can be lost. Which makes your statement about losing data not only false but backwards. Import may duplicate data, but it doesn't delete it or overwrite it, so you don't lose anything. However, sync replaces data, and even the most sophisticated algorithms can be wrong - and in fact are more likely to have bugs because of their additional complexity. I *have* lost data in sync operations, but never have with import/export. You are attempting to discount issues based on personal preference rather than taking a realistic view of how and when people - and their devices - work. You are doing this because you can't actually win the argument and you know it. If there were some kind of universal sync mechanism that worked on *all* devices and OSs, then yes, sync would be *the* way to go. But since few consumers will have any other Linux devices, syncing with the Tablets is going to be either impossible or very difficult for them. Which brings us back to the old: "Are these things for developers, or are they for consumers?" Get your story straight. I have never in my life seen more resistance to such a fundamental and important issue until I bought my N800. Your arguments are exactly the same as Nokia's regarding the absence of a PIM: "We don't want to, so we won't." There's no real foundation for your arguments. Mark _______________________________________________ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users