Mark wrote: > On Sun, Jun 22, 2008 at 4:24 AM, David Greaves <david@xxxxxxxxxxxx> wrote: >> 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. I'm getting a distinct cross-purpose feeling here. I'm talking about an approach to managing data. You appear to be talking about the availability of data managing implementations. I'm interested in making what we have better; you seem interested in making the best of what we have. I hope that's not too arrogant - please correct me if you are actually interested in abstractions rather than reality. >> 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. This seems like approach vs implementation again. Of course, until it becomes a standard then the proprietary players won't be interested and we won't be able to use it with them. Shame. Maybe we should stop doing 'open' stuff since it'll never catch on? I think the same argument applies with MS Office .doc vs ODF. > 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. I make no assumptions about implementation. I simply observe that you complain about some implementations and combinations. I have used sync that 'just works' (my work machine uses outlook and it syncs with an exchange server really well). Maybe I should be logging into exchange server, running a csv export every day and comparing it to a csv export from my outlook and then, well, I don't know. Does exchange have a csv import for one user? > 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. I do. I think that well designed solutions are better than quick hacks. Additionally quick hacks that move us towards well designed solutions are better than nothing. Worst of all are poor solutions that are persisted because some people don't think further than 6" ahead... >>> 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, Try this: "You are but a lowly user incapable of understanding the design of a genius such as I." Yep. that's more arrogant. > or more wrong. I hope so but I'm not sure - you tell me. I notice you didn't name one. (Note - I'm not talking about an implementation: syncing to a closed device that doesn't sync - I'm talking about a design situation) > 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: Actually it is; and I am living in a fantasy world. That's how (IMHO) good design works. One looks towards nirvana and takes a step. [snip lots of approach vs implementation confusion] > 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. I'm offline and manually delete a contact. Meanwhile my online inbox gets a new email with a vcard and adds it to the contacts. Still that could never happen. [snip solution that won't work in this case] > Sync is for lazy people who aren't very good at housekeeping. Oh, you're a Luddite now. Easy solution - just buy a wax tablet and stylus.... > 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. Yeah, like the wifi one on my N800/laptop that just reconnects when I get in range of an AP. A sync daemon that polls and notices a peer and auto syncs. How lazy of me. I just reconfigure it to forget my WPA pass phrase and flagellate myself as I use handwriting recognition, blind *and* with my left hand to re-enter the phrase using Kanji script. That'll prove I'm not lazy! > 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. Ah, never design anything where bugs could be bad. Must remember that one. > 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. You agree that I could if there were some kind of universal sync mechanism that works on all devices? 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. Ah, yes, you do. Good That's what I'm proposing. Should have one knocked up by the weekend. Then I'll just send out a chain email and the world will be using it by next thursday. Or maybe it'll be a touch harder. Does that mean we shouldn't try? > 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. Universal means more than just linux. > Which brings us back to the old: "Are these things for developers, or > are they for consumers?" Consumers who want to follow this approach: > 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. Yeah. That's a good sell for a consumer. "Buy my device - I know it's harder but you shouldn't be lazy". ROFL. The N800, as it stands, isn't a PIM. I think it should have superb PIM capabilities. Hopefully it will get them. > 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. Or "You're all wrong and I'm right". I feel so much better now you've let me know. David PS I did start this reply with the intention of trying to resolve our differences. However, after the cracks about arrogance, the total disregard for politeness, and frankly your rather closed attitude, by the end I think it's clear that we're going to disagree on this. I take your point that import/export are useful tools - however, IMAO, sync is the correct end-game target. _______________________________________________ maemo-users mailing list maemo-users@xxxxxxxxx https://lists.maemo.org/mailman/listinfo/maemo-users
