On Tue, Apr 9, 2013 at 4:27 PM, Marcin Borkowski <
address@hidden> wrote:
> I see. OTOH, one argument *against* a database (as opposed to parsing
> text files) might be exactly preserving the formatting etc. of files (of
> course, with all the syncing stuff this is not important anyway).
>
Certainly at the beginning it was easier to rely on our file parser and we tried to stick with that for as long as we could because in some ways it is just easier! We ran into some really nasty problems as we went along, though, and the further we got into our desired feature list the worse it became simply relying on that file parser. I was initially very skeptical about going the database route but it is easily one of the best decisions we have made with regard to refactoring of the project and it has enabled some of the great features we have today.
>
>
> That's interesting. I would be very glad to learn what might the
> pitfalls of "just overwriting files" be; it may be the case that "just
> overwriting" would work well with *my personal* use pattern of
> Org-mode, and that would be why I don't understand MobileOrg's approach.
So imagine this... in the morning you synchronize you org files to your mobile device but then make a change in one of those files and forget to push it up to your mobile. Later in the day you make a change to the same node, or even somewhere else in the file while on your mobile device and then push that file up. In the evening you get back to your computer running emacs and pull your remote changes in. What do you want to happen? Should the one still on your computer that you last changed this morning take precedence? or the one on the mobile device? The answer is probably that you want to merge those changes... that is something that emacs can do, but as is the case with most patch-work it can't always do that in automated fashion. That's why the org-mobile-* functions exist. Now it can be argued that there is a better way and I'd probably agree with that statement but it's not an easy problem to solve.
Here's another case... if you are editing a file in emacs and the file changes outside of emacs what happens? emacs doesn't like it at all... so you need some sort of built in emacs mechanism for being able to merge changes in a safe way, and it needs to not surprise the user when that's happening.
These are the kinds of issues we are all struggling to solve in one way or another but the general consensus is that "just overwriting" is the worst of the possible options, even if it is technically the easiest.
> * Yes, I did uninstall, but I've reinstalled MobileOrg again after
> reading this thread. I'll try to set it up again. I installed from
> the Google Play; is it better to use the github repo? It says
> "0.9.7" in the release notes on the wiki, Google Play says it's
> 0.9.8, and maybe it would be better to use master or even 0.9.10
> (looking at the branches on github)? Where do I find the info about
> installing the bleeding edge version from github on my phone (I'm
> quite new to Android, as I mentioned.)
Google Play is always up to date... usually we'll only post an updated changeset on github if something major has changed, if it's just a bug fix then you probably won't see it mentioned. If you can't access Google play, as mentioned in the wiki, you can always find the latest and past release here:
http://matburt.net/files/MobileOrg/> * I did not leave a one-star review; I guess I'm too lazy for that, but
> also it would be a bit unfair without further investigation of my
> problems.
I didn't mean to suggest that you personally did... but it happens a lot more than I wish it did. We also get faulted a lot for the perception of complexity of the way the we have to handle synchronization but as I've mentioned above... it's a little more complex than just pushing the files to the device or pulling them off the device.
> * I am very busy these days, but I'll try hard to start using MobileOrg
> and (if the problems I had persist), I'll try to report them on
> MobileOrg's mailing list. In fact, my problems were twofold:
> firstly, syncing didn't "Just Work™" (sometimes I got errors on
> MobileOrg, sometimes in Emacs), and some of the UI choices *did*
> suck. As soon as I find some time, I'll try to describe exactly what
> I mean by this, so that either it could get improved or I could get
> convinced that it's my usage that sucks (which is obviously possible,
> especially given my lack of experience).
Yep... the only way we know that it "sucks" is if people tell us what sucks about it. UI/UX has been an iterative process where we have to take feedback from our users. It's a real challenge to build a UI that works for the most people and we want to make the most people happy.