<html><head></head><body data-blackberry-caret-color="#00a8df" style="background-color: rgb(255, 255, 255); line-height: initial;"><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Not really. I do server software development. Java on Linux mainly. Although I write more code for these apps than for work these days. </div> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Michael<br></div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div id="_persistentHeader" style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>subharo@hushmail.com</div><div><b>Sent: </b>Saturday, September 7, 2013 4:52 PM</div><div><b>To: </b>otr-users@lists.cypherpunks.ca</div><div><b>Subject: </b>Re: [OTR-users] Pretty-please standardize OTR signature storage, per<br> OS.</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style="">Hello,<br><br>Thanks for the feedback an ideas! Glad to hear there is some <br>interest. :D<br><br>On Fri, 06 Sep 2013 14:25:35 -0400 "Daniel Kahn Gillmor" <br><dkg@fifthhorseman.net> wrote:<br><br>>I'm not convinced that just outlining a location in the filesystem <br>>for<br>>the data is sufficient, though, because of issues with concurrent<br>>updates; e.g. what if Alice's OTR-enabled tool X tries to make a <br>>note of<br>>Bob's fingerprint at the same time as OTR-enabled tool Y tries to <br>>make a<br>>note of Charlie's fingerprint?<br><br>Agreed.<br><br>>use of an agent-driven approach (e.g. a dbus query or talk to a <br>>local<br>>daemon bound to the loopback or something) could serialize and<br>>centralize access without causing more trouble. Related to <br>>earlier<br>>discussions about looking up long-term OTR identity keys in the <br>>OpenPGP<br>>keyserver network, it seems plausible that you could use a <br>>modified<br>>monkeysphere validation agent for this purpose; bummed i don't <br>>have time<br>>to work on it further at the moment, but if folks want to push in <br>>that<br>>direction, i'd be happy to kibbitz.<br><br>I was hoping for something simpler and more elegant than this. How <br>about simple file locks? If some flat config file (say, with OTR <br>fingerprints inside, with some nice XML or JSON markups or some <br>such) is in use by some IM client, that IM client "touches" (ie. <br>creates a file of size zero) a lockfile in the config folder <br>(having the same filename, but ending with ".lock"). Then one IM <br>client won't *write* to a config file if it sees that a lockfile <br>already exists (because some other IM client is already locking <br>it). And it can tell the user to "try again later" if so (after <br>checking itself a few more times, every few seconds).<br><br>This way, more than one IM client can *read* the config files at <br>once, but each IM client can only *write* to the files one at a <br>time. And a given IM client should *only* create the .lock files <br>for just as long as they're needed to make an update to the file, <br>like say < 1 second (just for *writing*). OTR fingerprints are <br>probably added by users rather infrequently (no thousands of <br>commits per second here!), so this simple method should suffice for <br>about 99.999% of all users, IMHO.<br><br>To make it even more "atomic", the new file is created with a <br>random suffix (a UUID), and then once the lockfile is in place, the <br>new file is "moved" overtop the old file, upon committing, then the <br>lockfile is removed. In the unlikely event that an IM client <br>crashes in the middle of that 1 or 2 seconds, then they'll have to <br>manually have to delete the lock file and pick which file is the <br>one they want, the new one (with the random suffix) or the original <br>one. And surely one of the two files is in a coherent, ungarbled <br>state, no matter at which instant a crash occurred. This is not an <br>uncommon way of "cheaply" implementing concurrency, as I'm sure <br>we've all had to delete a stale lockfile from time to time.<br><br>Sure, there are many sophisticated flatfile DB's one could use that <br>enforce concurrency (like say SQlite, or Python's Durus, which uses <br>nosql), but then you introduce more package dependencies, and you <br>make it less OS-agnostic. I think going the route of using some DB <br>will push a solution about 10 times farther away.<br><br>What I'm advocating here (via simple lockfiles, and almost-atomic <br>commits) is a decent, *OS-agnostic* solution, which is quite <br>elegant, and simple.<br><br><br>_______________________________________________<br>OTR-users mailing list<br>OTR-users@lists.cypherpunks.ca<br>http://lists.cypherpunks.ca/mailman/listinfo/otr-users<br></div></body></html>