Christian, The sync script isn't there because it hasn't progressed past proof of concept/reverse engineering hacks at the moment. I'm not 100% on it being a good idea. I'm not sure the api currently suits it and I'll have to break/customize the database schema locally.
Currently I add a remote_id column to the local tables which starts blank for locally added records and gets populated during sync, and I think I'd have to stop deleting rows and change to using a 'deleted' state. For the api I'm dumping the entire thing with xml_export and then adding/modifying/deleting as necessary (not very efficient, but todos.xml only returns active todos?). My musings on how this was going to work were as follows: Sync Strategy: A column is added to todos/contexts/projects that stores the corresponding remote id (refer to as localremote) 1. If item is added to remote: - We will have remote id, but no localremote or local id. Therefore need to add it locally. 2. If item is added to local: - We will have local id, but no localremote or remote id. Therefore need to add it to remote and store the returned remote id 3. If item is modified on remote: - Local will match remote id using localremote, but timestamp will differ. - Won't know if both have been altered? Either sync latest or prompt user. Could eliminate some of these by store a last sync time and descarding the old value. 4. If item is modified on local: - Local will match remote id using localremote, but timestamp will differ. As per 3. 5. If item is deleted on remote: - We won't find a match for localremote. As we know that localremote was only created to match a remote id we know it has been deleted. 6. If item is deleted on local: - We will have a remote id, but no localremote or local. - *****This conflicts with #1. Could check if remote was created before last sync time, or could store a deleted state locally. Wrote that when I thought I could manipulate the updated-at timestamp. Also had an issue last night where some (small percentage) of the pre-completed todos I added had their state reverted to active, so not sure the api likes those either. Cheers Steve On Tue, Dec 6, 2011 at 5:28 AM, Christian Frank <[email protected]> wrote: > > > Steve, > one more question on your sync problem: I didn't see the sync script that > you're developing in GitHub (maybe I missed it), but how do you know which > record IDs to pass back and forth? If the local and the server tracks dbs > were in sync before and you added a todo to each of them they would have > the same ID but be different todos. How (if at all) does your script deal > with this? Also, how do you deal with todos that are deleted either > locally or on the server? > > All, > based on the exchange with Steve this weekend I was thinking a bit more > about how to get an off-line client to work for airplane rides, etc., but > also for use across slow or expensive connections where working on-line is > just too painful. Something along the lines of offline email where you > replicate your new / changed email to the local machine, work with it and > every once in a while replicate it back to your central mail file on the > server. > Note, I'm not advocating re-architecting Tracks into a client / server > app, but I'd like to be able to create a client that uses Tracks as if it > were the server. > > For the client, I like the idea of just using a locally installed copy of > Tracks because it avoids reinventing the wheel, and can be kept current > with minimal effort. It would be a little heavy, because of the DB, web > server, RoR, but better that than having to maintain more code. The poor > man's version of this idea would be to have a single database and do some > sort of checkout / checkin every time you go on the road, or Steve's > dropbox approach. It would work right now, but it's not very practical in > the long run. > > Another option, and the one I'd like some feedback on, is to allow the > local copy and the server copy of Tracks to synchronize. Since rails IDs > are not unique across clients, it seems to me that we would need to start > with assigning GUIDs for each context / todo / project (=CTP). During > replication the client(s) need to check if a local CTP's GUID is dirty > which means it needs to be replicated. The server needs to send all CTPs > that had any changes since the last replication with that client. Further, > the client(s) and the server would need to keep a list of GUIDs for > deleted todos, in case of the server almost indefinitely, in case of each > client until it has pushed the delete to the server. Dealing with > dependent actions would be tricky and I would expect a bunch of nasty > corner cases, but does this seem workable to you all? > > Also, what is the overall interest in an off-line / slow line client? > > Lastly, is there a better answer that would also work on tablet / phone > platforms? > > Best > Christian >
_______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
