Server/client model
Here’s a diagram showing the server/client model for Beyond (you can click on it for a slightly larger image):
I think the image pretty much speaks for itself. The only thing not accounted for is that desktop clients will probably need to have a mini-server for offline editing (they’ll need to implement the Beyond API themselves, and then switch between calling it and the API on the server, depending on whether they’re editing online or offline). For offline editing, SQLite will probably be the best way to go.
Posted in Design, Development
Comment feed for this post
I just noticed the separation of the web client from the Beyond server… does this mean people can mix and match servers and clients, so that you don’t have to have the Beyond client to use the Beyond server?
Exactly. I don’t see the Beyond web client necessarily supporting other servers at the moment (mainly because I don’t know of any in existence :)), but you’ll certainly be able to use other clients to access the Beyond server. That’s where the API comes in — it’ll be accessible enough that you could write any kind of client in pretty much any language. It also means that people who need specific functionality not supported by the official clients can write their own apps with a minimum of effort. (And of course user data will only be accessible after proper authentication. :))
It’s like the web — the web server doesn’t really care which browser you’re using (we’ll ignore the small incompatibilities for now :)), so you can use Firefox, Safari, Internet Explorer, Opera, Lynx, or pretty much anything else that speaks HTTP. As you can use wget or curl (or any of a host of other utilities) to download a web page without using a browser, you could write a little utility (in Python or Lisp or C or whatever) that downloads your genealogical data and converts it to a certain format for statistical analysis, or pretty much anything else.
The goal is openness. Users should be free to use their data however they want.