On Sun, Jun 22, 2008 at 4:24 AM, David Greaves <david@xxxxxxxxxxxx> 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@xxxxxxxxx
https://lists.maemo.org/mailman/listinfo/maemo-users
