Re: Synchronization puzzle - take care!
On 10 Nov 2005, at 03:03, Alex Tweedly wrote: Sorry about the problems. I find it's one of the biggest problems with Rev's "live IDE" style - it's so hard to ensure that you are properly emulating a "cold start". Not at all - thanks for sharing it! ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle - take care!
David Bovill wrote: Thanks for posting this Alex - word of warning and feature request for RunRev - or is as ever there a way I haven't spotted? First the warning - downloading the stack "Networked Address Book" from revOnline automatically asked me to locate x,y, z - can't remember - to which I naturally said no - then got myslef into an endless loop of answer dialogues! This is a rough edge I wasn't expecting anything as fundamental as this. It turns out there is an initialization problem (which of course I haven't seen - haven't installed this on a new machine since January). The start-up sequence is 1. read prefs file 1a. if there is no prefs file, prompt user for basic data and create one (basic data = machine name and folder to store address book files in) 2. read data file(s) 2a. if there is no data file, create an empty one and store it in the folder specified in the prefs file repeat the above steps until both files can be read OK. Problem 1. I was omitting step 2a :-( Now fixed (v 0.9.4, already uploaded to revonline) Problem 2. This will not work in the Player in secure mode. Since there's not much point in an Address Book that can't store its data, I'm not going to worry about this. Problem 3. Even in non-Secure mode, it doesn't work properly in the Player. Works fine in the IDE, or as a standalone - but not in the Player. Since it's not an app that I would expect anyone to run, rather than borrow parts of the script, getting it to work in the Player is not a priority, I'll look into it when I have time, and if appropriate open a BZ. For now, please download it from revonline using the IDE. Now the question is - is there a way to cancel an answer dialogue? Command period does not work - unless you are lucky and the script loop is long - sometimes I manage to break out. I think it would be very useful if there was a way to do this as the only way I know is to force quit and loose all your unsaved data! Easy to do - done it many times myself ! Sorry about the problems. I find it's one of the biggest problems with Rev's "live IDE" style - it's so hard to ensure that you are properly emulating a "cold start". -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 05/11/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle - take care!
Hi David, Just use the contextual menu as I explained it in a previous post to Jan (4 hours ago) and toplevel the answer dialogue :-) All is now accessible... If you are asked to save the dialogue when closing it, just don't save it ;-) Best Regards from Paris, Eric Chatonet. Le 9 nov. 05 à 22:55, David Bovill a écrit : Now the question is - is there a way to cancel an answer dialogue? Command period does not work - unless you are lucky and the script loop is long - sometimes I manage to break out. I think it would be very useful if there was a way to do this as the only way I know is to force quit and loose all your unsaved data! So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Free plugins and tutorials on my website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle - take care!
Thanks for posting this Alex - word of warning and feature request for RunRev - or is as ever there a way I haven't spotted? First the warning - downloading the stack "Networked Address Book" from revOnline automatically asked me to locate x,y, z - can't remember - to which I naturally said no - then got myslef into an endless loop of answer dialogues! Now the question is - is there a way to cancel an answer dialogue? Command period does not work - unless you are lucky and the script loop is long - sometimes I manage to break out. I think it would be very useful if there was a way to do this as the only way I know is to force quit and loose all your unsaved data! Easy to do - done it many times myself ! On 9 Nov 2005, at 20:10, Alex Tweedly wrote: The synch method I used is described in http://lists.runrev.com/ pipermail/use-revolution/2005-January/049974.html along with some justification for why this method is needed (basically, I needed a scheme with no central "master" copy, and the ability to synch together any two copies that happen to come together at any time). Would love to have a look - but scared to download again now :( The sync idea is (I think) good and general (I use it for address, calendar and notes - but the sync'ing is done without regard to the content). The stack is usable, but has more rough edges than it does smooth bits. I noticed :) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
David Bovill wrote: I'd be interested in this for the Address Book app I'm working on. Not addressed the issue of data synchronisation in any depth yet... The stack is now on revonline (username alextweedly, category: General), called something like "Networked Address Book". The synch method I used is described in http://lists.runrev.com/pipermail/use-revolution/2005-January/049974.html along with some justification for why this method is needed (basically, I needed a scheme with no central "master" copy, and the ability to synch together any two copies that happen to come together at any time). The sync idea is (I think) good and general (I use it for address, calendar and notes - but the sync'ing is done without regard to the content). The stack is usable, but has more rough edges than it does smooth bits. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 05/11/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
I'd be interested in this for the Address Book app I'm working on. Not addressed the issue of data synchronisation in any depth yet... On 8 Nov 2005, at 18:22, Dave LeYanna wrote: I was searching the archives looking for some information about a PIM lib or stack that may be available and noticed your post about syncronization issues you were looking at. Did you ever finish that addressbook app? would you be interested in sharing or selling it? We need to develop a PIM and an address book is part of such an application. We probally will be using PostgreSQL on a server with SQLLite on the desktops that will need to sync once connected to the network or via the internet. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
Thanks Alex! Dave Alex Tweedly wrote: Dave LeYanna wrote: Alex; I was searching the archives looking for some information about a PIM lib or stack that may be available and noticed your post about syncronization issues you were looking at. Did you ever finish that addressbook app? would you be interested in sharing or selling it? No, I didn't "finish" it. But I (and the rest of my family) now use it as *our* shared addressbook. It's a long way from finished - somewhere I have a long list of things that need done before I can "release" it, but it already does enough to be more useful (in my unusual circumstances) than any other addressbook I've ever found, so I'm using it happily and the other improvements are low priority. The initial posting about it received only one (slightly discouraging) reply, so I never did get around to posting the stack anywhere. We need to develop a PIM and an address book is part of such an application. We probally will be using PostgreSQL on a server with SQLLite on the desktops that will need to sync once connected to the network or via the internet. The synchronization scheme I have may be overkill - multiple people independently and asynchronously (off-line) editing a fully shared addressbook or calendar, and may also be inadequate in other ways (it is a single shared addressbook/calendar, with no mechanism to have separate views or to sync or co-ordinate between such multiple data sets). So I'd recommend a careful look over the "synchronization spec" part of my earlier email to make sure it is suitable for you. I have currently only implemented the "shared file system" sync method - though I did use the basic technique in another app where I implemented the server/client method (not in Rev), so I feel comfortable that it works and saves bandwidth. It should extend easily to PostgreSQL - an initial query to retrieve the control fields for all records, with subsequent retrieves of the rest of the data only for the updated records. I'll clean it up, remove my own data :-) and put the stack up on revonline tonight. The stack carries many footprints of the fact that I initially intended to make it a single "PIM" - and later changed my mind and did separate addressbook and calendar apps. For instance, right now there is a "tabbed notebook" with only the single tab for addressbook. btw - I'm not interested in selling it, but if you find it useful and use any (enough) ideas from it (esp the sync scheme which afaik is novel), I'd appreciate a mention in the credits/footnotes. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
Dave LeYanna wrote: Alex; I was searching the archives looking for some information about a PIM lib or stack that may be available and noticed your post about syncronization issues you were looking at. Did you ever finish that addressbook app? would you be interested in sharing or selling it? No, I didn't "finish" it. But I (and the rest of my family) now use it as *our* shared addressbook. It's a long way from finished - somewhere I have a long list of things that need done before I can "release" it, but it already does enough to be more useful (in my unusual circumstances) than any other addressbook I've ever found, so I'm using it happily and the other improvements are low priority. The initial posting about it received only one (slightly discouraging) reply, so I never did get around to posting the stack anywhere. We need to develop a PIM and an address book is part of such an application. We probally will be using PostgreSQL on a server with SQLLite on the desktops that will need to sync once connected to the network or via the internet. The synchronization scheme I have may be overkill - multiple people independently and asynchronously (off-line) editing a fully shared addressbook or calendar, and may also be inadequate in other ways (it is a single shared addressbook/calendar, with no mechanism to have separate views or to sync or co-ordinate between such multiple data sets). So I'd recommend a careful look over the "synchronization spec" part of my earlier email to make sure it is suitable for you. I have currently only implemented the "shared file system" sync method - though I did use the basic technique in another app where I implemented the server/client method (not in Rev), so I feel comfortable that it works and saves bandwidth. It should extend easily to PostgreSQL - an initial query to retrieve the control fields for all records, with subsequent retrieves of the rest of the data only for the updated records. I'll clean it up, remove my own data :-) and put the stack up on revonline tonight. The stack carries many footprints of the fact that I initially intended to make it a single "PIM" - and later changed my mind and did separate addressbook and calendar apps. For instance, right now there is a "tabbed notebook" with only the single tab for addressbook. btw - I'm not interested in selling it, but if you find it useful and use any (enough) ideas from it (esp the sync scheme which afaik is novel), I'd appreciate a mention in the credits/footnotes. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 05/11/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
My bad, should have been a personal email... However, if anyone knows of some tools or stacks that I can use/buy to implement a PIM please let me know... Dave Dave LeYanna wrote: Alex; I was searching the archives looking for some information about a PIM lib or stack that may be available and noticed your post about syncronization issues you were looking at. Did you ever finish that addressbook app? would you be interested in sharing or selling it? We need to develop a PIM and an address book is part of such an application. We probally will be using PostgreSQL on a server with SQLLite on the desktops that will need to sync once connected to the network or via the internet. Thanks in advance Dave LeYanna ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Synchronization puzzle.
Alex; I was searching the archives looking for some information about a PIM lib or stack that may be available and noticed your post about syncronization issues you were looking at. Did you ever finish that addressbook app? would you be interested in sharing or selling it? We need to develop a PIM and an address book is part of such an application. We probally will be using PostgreSQL on a server with SQLLite on the desktops that will need to sync once connected to the network or via the internet. Thanks in advance Dave LeYanna ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
I wrote: [ slightly OT - this is a "design / algorithm" question rather than a Rev/xtalk one, really ] [and it's a long, rambling email - so feel free to skip it] You just can't get good staff these days :-) My typist (that's me) missed a crucial sentence or two when transferring hand-written notes to email. same ID. compare 'last-events' : same : everything is good, advance both current counters. different - but the last-event machine is the same take whichever entry has the later edit time (note - from same machine, so they can be compared), and add to the other database advance both counters different - and different machines: if my 'ID + last-event' is in his history database - his entry is later ACTION : add his entry to my database OR if his 'ID+last-event' is in my history database - my entry is later ACTION: add my entry to his database if all data fields are identical - skip, no action needed. there is no way to tell which is later - user needs to resolve differences, or postpone. then advance both counters. I should have just sent the code . -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
Stephen Barncard wrote: Why bother with sync at all? That looks like a nightmare! Because I need it. Are all your workstations internet-connected? No. Some of them are some of the time, but in general they're not. And it's not acceptable to be unable to make edits when they're not connected. I think any "delayed update" of a central database finishes up being equivalent to this problem - there is a small gain from being able to know that there is a single central "master" version, but it's a pretty small difference. Why not create a MYSQL database and any number of clients made in Rev to talk to it. Most good ISPs offer it. Yeah, all 3 of the ones I use offer MySQL (and CGI scripts if I needed that). All data will be real-time - no copies needed. Very simple. Simple, but not applicable. If enough of them were connected enough of the time, I'd probably do as you suggested, with a local cache inside the Rev app on each machine - but unfortunately that's not the situation I face. Thanks anyway -- Alex. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Synchronization puzzle.
Why bother with sync at all? That looks like a nightmare! Are all your workstations internet-connected? Why not create a MYSQL database and any number of clients made in Rev to talk to it. Most good ISPs offer it. All data will be real-time - no copies needed. Very simple. [ slightly OT - this is a "design / algorithm" question rather than a Rev/xtalk one, really ] [and it's a long, rambling email - so feel free to skip it] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Synchronization puzzle.
[ slightly OT - this is a "design / algorithm" question rather than a Rev/xtalk one, really ] [and it's a long, rambling email - so feel free to skip it] I am in the process of writing my own Address Book application. That may sound like an odd thing to do : aren't there already hundreds of programs to do that already ? isn't there an address book built into the OS and/or major apps ? can't you get everything from freeware to professional apps to do that ? what's wrong with the software that came with your Palm Pilot (or PDA, or Pocket PC, or ) why re-invent the wheel ? The reason that none of them quite satisfies my needs is simple - I want a shared address book, between myself, my wife and various other family members. There need to be up to 8 different computers running this application - all of them on a network, but never all on the same network. There are two separate home networks, plus maybe a server on a web-site somewhere so I can use it from anywhere with an Internet connection; the 3 laptops will intermittently appear on one or other network. Any person can make updates to the address book, and I want a simple way to synchronize those changes on to the other instances of the app. What I've been doing until recently was using the Palm Desktop software that came with my Palm Pilot on each machine; periodically I would sync the Palm Desktop to my Palm Pilot, then re-connect the Pilot to another machine and sync there, then to another, then . which all worked OK, though it's a bit of a drag connecting the Pilot to the serial port of each machine in turn. And it just seems crazy when they're connected together by 100M Ethernet :-) But now the two newest machines don't have a traditional serial port, only USBs. So I have the choice of spending £29.95 for a cable or tens (hundreds) of hours writing software - no competition :-) I looked at using the Palm database, and simply (??) writing an app to sync databases - but the combination of incomplete documentation on the format (not to mention its complexity) and concern that I might conflict with Palm's synchronization technique has put me off that. I should mention that I never (or very, very rarely) actually use the Palm Pilot for anything other than this synch'ing effort. The Palm Pilot is almost never carried around; it has, for me, been squeezed out of its niche by my laptop one one side and my cell phone with its 100+ phone numbers and storage for many SMS messages on the other. (I sometime text myself an address or directions if I think I'm likely to need it and won't be taking the laptop - or occasionally even use pen+paper !!) What I'm looking for, then, is a method to do "peer-to-peer" synchronization between an undefined number of instances of the address database. I've got a design, I've thought it through as much as I can, I've done "dry-run"s on paper to check it works, I've implemented it and tested it - but I'm still concerned that I've missed something, and that it will fail in some circumstances. Here's the relevant section of my "design document" (i.e. transcription of the scribbling on the back of an envelope); I'd be very grateful for any comments, corrections, etc. On the other hand, if there is some standard technique or algorithm for doing this, and I just didn't know about it (and couldn't find it in a Google search), then a pointer to a good description would be also very useful. --- Synchronization. All synchs are user-triggered - i.e. a user on one machine will trigger a sync to another machine; the user is available to resolve anyh conflicts immediately) or she can choose to postpone that part of the synchronization until later. The two machines must be networked together at the time of a sync. That sync can use any of: - shared file systems (e.g. laptop to file server) - http request / post (e.g. laptop to web site) - TCP based connection (e.g. laptop to laptop while on same network). (I don't export the filesystems on the laptops, nor do I run http server on them, so the plan is that each machine can run a address-book-sync server that will accept TCP connections on some odd port, and transfer data that way). The fundamental sync algorithm is the same in each case; the description below is written as though the synching machine had complete access to the 'other' address files. The optimizations possible to avoid complete transfer of the data should be apparent - but in fact for my address book, the whole file is probably never going to be above 100K, so it's not clear if those optimizations are worth the implementaion effort. Time synchronization. It cannot be assumed that the clocks of the different computers are in sync, even approximately. It can (and will) be assumed that each computer's clock will return times that are continuously increasing. (Yes, I do know about NTGP, and SNTP, and TSP, and various
