TntMPD 2.1 r24 (beta) -- Dropbox

Hey thanks very much for the work on this.  I can see great value in these new features.

I haven't used Dropbox much but after reading the article it sounds like they have a "safer" way of handling file conflicts - lessening the chance that your TntMPD DB will be inadvertently overwritten.

  I use Google Docs far more often for similar purposes in MPD. Has anyone tested this functionality by prompting TnTMPD to open a Tnt database stored on Google Docs?

@Troy - this will be so helpful and solve a problem that my wife and I are currently experiencing.  (We use dropbox to coordinate our use of TntMPD).

@David - how do you open a file locally that is stored in Google Docs?

@Troy -- Just worked some experiments with the new release, and with both of us trying to get in/out of the database. I think the concept is almost there, but let me outline a scenario and see if I'm making sense. Our setup is probably similar to others. My work computer and my wife's computer each have a copy of Dropbox under the same account, so in essence there's a triangle with Computer A and Computer B as the base, and the Dropbox cloud as the apex, and a copy, hopefully fully in sync, of the TntMPD DB in each location.  OK, so it appears that when User A opens TntMPD, he/she gets a LOCK file with their computer info opened locally. That lock file is transmitted around the triangle fairly efficiently by Dropbox, so that a few seconds later, if User B tries to open it on their computer, they get the warning that USER A HAS THE DB OPEN. All good so far. However, if User B decides to bypass the warning (maybe User B is just needing to view an address or some such), what appears to happen is that the LOCK file is updated to now indicate that User *B* is in control. Then, User B closes the app, and it looks like you have logic that says, "If the user who 'owns' the LOCK file exits, go ahead and delete the LOCK file." Because then User A gets a notification that "DB.LOCK file has been deleted." And if User B tries to then go back into the database, even while User A still has it open, User B goes straight in without a warning. Make sense? (And do we agree that's still a bit of a problem?) From where I sit, the lock file should stay with the user who originated it. If folks bypass the warning, they know that any changes are going to potentially create a problem, and do so at their own risk. When the lock originator leaves the app, THEN the lock file can be deleted with their departure, and either user(s) can go in without warning from that point forward. Thoughts?

I was definitely not thinking in terms of a read-only version of the database. But I would argue that there IS value in letting a user into the database WITHOUT taking over the lock. If they are, as in my scenario, just viewing stuff that they need at that moment, no harm will come of it, and if they do wind up changing anything, the conflict entities created by DropBox will still allow for synchronization after the fact.<br><br>I can see why you would ALSO want them to be able to take over the lock, in case there's some hiccup and a stale/stray lock file is sitting around in the mix, but I do think allowing a de facto read-only copy (without you having to code for it) is useful as well. <br><br>To that end, perhaps simply altering the dialog (and the corresponding actions) would be appropriate? <br><br> The database file is in use by another user... Do you want to... (1) open the database to make changes anyway? (2) open the database for viewing only? (3) exit.  <br><br>In this instance, (1) would be the current "No" behavior, (2) would be my proposed "don't let me alter the lock file" behavior, and (3) would be the current "Yes" behavior. You could add the current "Cancel" as a fourth option as well. <br><br>I would not recommend automated, time-sensitive overriding behavior. <br><br>As always, thanks for entertaining our input, Troy. We really appreciate all you're doing.

Well, than that's clearly not a good use of your time; there are a number of alternatives to address my concern short of you having to develop the read-only capability, and the gain in flexibility is not worth the effort. So the moral of the story is that as you say, bypassing the lock is only for those circumstances when the lock is being held in error somehow, and it's necessary to "take it over" yourself. Not to keep the concept alive, but rather to perhaps eliminate the need for the separate lock file -- would it not be possible to simply set up a lock table in the db schema that performed the same function? Wouldn't change any of the behavior you desire above, but would just be one less moving part. I suppose that would have implications for TntSync, though, so perhaps that's why you've gone this route? Again, thanks for entertaining my random sludge of ideas.

For what it's worth, simply having the ability to "lock" the database so that multiple users can share a copy would be a huge win.  

In my opinion having that is better than a read-only mode.

In the circles I run in, a lot of couples work on MPD together and would benefit hugely from being able to both have a copy of the database sync'd via dropbox.

That is so awesome, Troy.  Thanks so much for your work on this.