So after I have read your (Tracy) last post multiple times, I must say that it helped me much to understand what you wanted to say
That does not necessarily mean that I totally agree with everything
I'm glad that we're making progress with understanding one another. And, of course, I don't expect you to agree with everything I say.
Let me preface this with a tiny mini-biography of me, to make my biases clear: I am not a professional software developer, though I do spent a fair amount of my time developing software for my own use. I studied math at uni, and I tend to enjoy functional programming (Haskell is a beautiful language!), so my problem-solving strategy typically involves breaking problems into pieces that can be solved by functions that are small enough to be 'obviously correct'.
Anyway: my immediate reaction to the idea of a single piece of software that manages a game database, provides a communication system (including maybe both private messages and forums), allows moderated editing, and who-knows-what else is that this is a piece of software that has too many hats to wear, and development and maintenance will be simplified by breaking it into multiple applications. So, for full disclosure, if you prefer developing big, monolithic pieces of software, we're going to have some philosophical disagreements.
Since terminology has been a problem, let me set out by clarifying my terminology:
gene wrote:If we split our application as you are describing it that would technically mean:
1) database server with REST interface (Java/REST + database)
2) user server with process logic and user persistence but without GUI (Java/REST with database)
3) HTML+JS application with GUI
Let me call 1) the database server, 2) the moderation server, and 3) the client. I recognize that the second may be handling things like messaging as well, but let's keep it as simple as possible.
gene wrote:I cannot see why we should not be able to guarantee that one part of the application (read game data) is stable while another part of the application (contribution process, user management/features) is under development? And I don't think that we will mess up the machine/process so much that it will refuse to work completely.
Well, of course with proper care and discipline, we should be able so sufficiently isolate changes that we don't make any huge mistakes and break unrelated parts of the server. But, every time we are touching the same codebase, we do have a risk (if slight) of breaking things unintentionally. This is especially the case if the different parts of the software are not really well separated. But, point taken: we don't have
to have actually different pieces of software, as long as we're careful about keeping things loosely coupled.
gene wrote:Your last point (data imports from other databases) is only a "functional" thing. Of course it would be nice to offer a feature to import data from other databases with a special support, but again I don't see why this would lead us to the need to seperate our application in two.
This point was in response to the idea that you must have the user database on hand to do change attribution. If that's really true, then it means that you're doing it by linking against the user table, or something, and I was making a point that there were other attribution scenarios where that wouldn't be a good idea--and therefore you probably don't
really need the user table on hand.
gene wrote:That makes three applications to develop. I don't want to start three application servers (plus the two database servers) for development!?
Well, it might be inconvenient for the moment, but if I dream that in the future we may have a very popular service, it seems to me that we might well want to be able to put the (relatively) high-traffic database server on a different machine (or in a different instance in the cloud, or whatever) from the (relatively) low-traffic moderation server. This especially if there's heavy development: we could bring the moderation server down for work as often as needed without disturbing the database server.
gene wrote:Another reason why I don't like to split the "client and server" like you are suggesting:
parts of the datamodel must be doubled. Most of the game datamodel, as you can send in game data on your "client". And also parts of the user datamodel, as I want to store next to the game data which user entered the data, which user commented on which data, which user approved which game data and so on. You see: I don't want to seperate these data sets, because I thing they have too many relations.
Here I disagree. The client that we have now does not need to duplicate the data model to display the data, and there's no reason why my proposed design would require it, either. I don't know exactly how you plan for the contribution process to look 'under the hood', so let me imagine an example of how it might work, to show why I think this way. (Note that the example isn't intended to represent our actual data model, etc. I just intend to show the process.)
Code: Select all
HTTP GET http://api.oregami.org/games/1
"title": "Monkey Idland",
Oh no! A typo! To fix it, the moderation server might send back something like:
Code: Select all
HTTP PATCH http://api.oregami.org/games/1
"title": "Monkey Island"
Of course, in my proposed design, the actual patch contents would have the change attribution and some other metadata, but you see my point.
Now, for the client to display the modified version before it's sent to the server, it just has to apply the patch itself--but at no point does it really need to know anything about the data model. It's just working with a JSON object.
Now, I agree that the client UI will need to in some sense duplicate the data model by providing forms to fill out to add games, and by knowing that a game has for example a 'title' attribute that can be displayed in the page title, but that's duplication that would occur regardless of where the data model is stored.
As for the other part, I don't think that the database server must store the user table, either. We could imagine that the 'attribution field' for the change is some free text field which can be populated by the moderation server on making a change with something like: "Modified by <a href="http://moderation.oregami.org/user/2733">Tracy
Poff</a>. Approved by <a href="http://moderation.oregami.org/user/2309">gene</a
>." Then for change history we have Envers or whatever providing the historical contents of the field... well, that's all just matter of implementation. The point is that we can certainly attribute things properly without the database server having the user table on hand.
gene wrote:Abour your OpenID-thing
I was just giving an example of authentication being handled by something other than the app that needs the authentication, so please forgive me if I don't pursue this any further. Of course I agree that the scenarios are different.
Now I've written another huge post, so big that I can't remember whether I said everything I wanted to when I started writing. I'm sorry about that--I don't mean to make it a habit.
It looks like, in the end, you think my idea will complicate development (and maybe have other drawbacks), and I think that it will simplify development (and maybe have other benefits). I'm not exactly sure where to go from here...