What is usenet for databases?
Apr. 9th, 2008 07:43 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jackRecently my "books lent and borrowed" list ballooned by 100% or more, and it occurred to me how useful this would be if it were stored in a simple database, so "Jack, friend, lent/borrowed, book" would automatically contribute to friend's list as well. (You might make a few tweaks on a server large enough that everyone doesn't automatically trust each other such as recording if both people have approved the entry.) And if it's returned, either of us can check it off.
Obviously someone used to web programming could knock up something that works in a simple way in an evening if they put their mind to it (though I'm rather rusty myself).
However, this is obviously limited by server. Someone would write it and host it on chiark, or other server, and invite people to use it, but if someone elsewhere did the same thing, you'd have to have an account on both if you had friends on both. (Which isn't a big deal for _this_, but I'm curious, and would be great for many applications, maybe even social networking ones.)
What is the most obvious way of letting the two (or many) servers cooperate? Tim described this as "usenet for databases". Mobbsy said the nearest thing that sprang to mind was DNS, which do trade information back and forth. You might find the bandwidth wasn't even that high -- eg. many web apps send email alerts anyway, so the extra hit of sending the data to another server mightn't be so much extra.
(I'm more interested in the question about the technology of distributed databases, but I'm interested in the book thing too -- I haven't searched yet, so it probably exists, or can be integrated to librarything or similar, and if you know of it please do tell me, but that wasn't the real reason for the post.)
(Another wrinkle is my envisaged service/applet/facebook-app I may have mentioned before called "not a bank" which does the same thing as book loans but for money and other fungible amounts, where it can be automatically rebalanced so all your debts cancel out and you owe/are owed by just one person you know. It would be emphasised this was an aide memoire for small loans to someone you trust to pay, or don't care if they don't, but you might not remember.)
(Distributed databases have lots of problems with being transaction safe and not getting data desynchronised between servers, etc. These applications seem superficially more suited as: each person can have a home server that might be considered authoritative; or at worst one server has to push a change to another one; and should be low risk if something does go wrong. A big headache (or showstopper) is security, need servers trust each other? Can you arrange it so if some idiot trusts a friend on a bad server, the worst that happens is they individually get spammed, but not actually corrupted?)
Obviously someone used to web programming could knock up something that works in a simple way in an evening if they put their mind to it (though I'm rather rusty myself).
However, this is obviously limited by server. Someone would write it and host it on chiark, or other server, and invite people to use it, but if someone elsewhere did the same thing, you'd have to have an account on both if you had friends on both. (Which isn't a big deal for _this_, but I'm curious, and would be great for many applications, maybe even social networking ones.)
What is the most obvious way of letting the two (or many) servers cooperate? Tim described this as "usenet for databases". Mobbsy said the nearest thing that sprang to mind was DNS, which do trade information back and forth. You might find the bandwidth wasn't even that high -- eg. many web apps send email alerts anyway, so the extra hit of sending the data to another server mightn't be so much extra.
(I'm more interested in the question about the technology of distributed databases, but I'm interested in the book thing too -- I haven't searched yet, so it probably exists, or can be integrated to librarything or similar, and if you know of it please do tell me, but that wasn't the real reason for the post.)
(Another wrinkle is my envisaged service/applet/facebook-app I may have mentioned before called "not a bank" which does the same thing as book loans but for money and other fungible amounts, where it can be automatically rebalanced so all your debts cancel out and you owe/are owed by just one person you know. It would be emphasised this was an aide memoire for small loans to someone you trust to pay, or don't care if they don't, but you might not remember.)
(Distributed databases have lots of problems with being transaction safe and not getting data desynchronised between servers, etc. These applications seem superficially more suited as: each person can have a home server that might be considered authoritative; or at worst one server has to push a change to another one; and should be low risk if something does go wrong. A big headache (or showstopper) is security, need servers trust each other? Can you arrange it so if some idiot trusts a friend on a bad server, the worst that happens is they individually get spammed, but not actually corrupted?)
no subject
Date: 2008-04-10 09:53 am (UTC)It gets much trickier if there's no definitive truth.
Yeah, quite.
But what if each datum has one of the servers authoritative? That's what I was groping toward in one of my footnotes, that the data is only really betweeen two people, and is an incredibly simple mostly-forward only state-machine. Say chiark is authoritative for "books Jack has lent", and any "i have borrowed X from Jack" become requests for me to confirm. (Which could be automatically if it's a person I trust on a server chiark trusts.)
There's no central truth, but for each datum, it ought to work the same way as if there were a root authority and servers which mirror it. "I have borrowed X from Jack" are routed to chiark, and the confirmation is sent back, and anyone who is allowed to search my listings for X can request a list from chiark to be passed to their server. Maybe.