Open Registry of Game Information 

  • Proposal: Authentication and Separation of Concerns

  • All things about Java, JavaScript, HTML, Git, whatever is useful for developers.
All things about Java, JavaScript, HTML, Git, whatever is useful for developers.

Moderators: MZ per X, gene

 #37712  by gene
 05 Dec 2013, 23:28
Let's get on track for this topic again as it's rather important.

I am still not with your opinion for the following reasons (I'll try to make it short and precise):
  1. I don't agree that just because one part of an application (contribution process) is not so frequently/massively used as another part (read/display game data) it should be built as a seperate application. And as I said before, in my opinion it cannot be a criterion that one part of the application should get more stable by seperating other parts of the application from it.
  2. The history of a game data set is in my opinion directly coupled with the user(s) who edited this data set. You propose that we document the metadata of data changes with a text field - no way! It must be possible to view a detailed list of "who edited what game data when" and display this data directly together with the game data. This information should in my opinion also be retrievable from the application via REST calls. Just like (nearly) every data from our application. We must be able to answer a request like "list the games that user X contributed to in the last year".
  3. During the contribution process users will enter game data. This game data needs to be saved temporarily in my opinion before the contribution is finally "submitted". Just like a shopping basket in an online shop. We will offer quite complex HTML forms (game data, source infos, upload files), so the user must be able to save the game data from the current contribution. Therefore we need an implemented game data model - and not a second one, but the only one. A "moderator" has to take a look at the contribution data bevore he can approve it. Or only some parts of it. For all these things I want to build just one integrated data model - not two seperated.
  4. For maintenance purposes we may always use HTTP techniques - just add a new server instance and then turn of the old one - like a load balancing server. One may divide an application into two applications for that - if there were no other reasons for not doing this. But I think there are reasons why we should not make two applications.
Do you still want to convince me? :roll:
 #37716  by Tracy Poff
 07 Dec 2013, 02:37
I am prepared to abandon this proposal, since you haven't found my arguments to be convincing. I'm not so arrogant as to think I've got the One True Solution and couldn't be mistaken, of course.

That said, I will answer your concerns, just for the sake of clarity and a sense of closure.
gene wrote:I don't agree that just because one part of an application (contribution process) is not so frequently/massively used as another part (read/display game data) it should be built as a seperate application. And as I said before, in my opinion it cannot be a criterion that one part of the application should get more stable by seperating other parts of the application from it.
I'm not sure if you're saying that you don't think that separating the application into smaller pieces will make any individual part more likely to be stable, or of you're saying that you don't think that's a good enough reason to do it. Either way, that wasn't my whole reason for wanting to separate the parts: in my opinion the moderation/contribution part is different enough from the database part that it would be rational to separate them, even absent any other benefits. I recognize that you think separating them is a bad idea, for the following reasons, among others...
gene wrote:The history of a game data set is in my opinion directly coupled with the user(s) who edited this data set. You propose that we document the metadata of data changes with a text field - no way! It must be possible to view a detailed list of "who edited what game data when" and display this data directly together with the game data. This information should in my opinion also be retrievable from the application via REST calls. Just like (nearly) every data from our application. We must be able to answer a request like "list the games that user X contributed to in the last year".
I was I guess not too clear on this, but I did imagine that the text we stored would be structured, so you could still do all that stuff, albeit with a little program logic involved rather than just a database call. I'm sure you realize that if each historical version of the 'contributing user' field contained the user responsible for that version of the thing, then we could walk through the history to pick up a list of historical contributors, together with the times of their contributions. And, naturally, if we used structured text then we could always have a SQL query with "WHERE Contributor LIKE '%<link rel="author" href="http://client.oregami.org/user/1234">%'" or whatever to get those kinds of things. I definitely wouldn't agree with any proposal that harmed our ability to retain authorship information!
gene wrote:During the contribution process users will enter game data. This game data needs to be saved temporarily in my opinion before the contribution is finally "submitted". Just like a shopping basket in an online shop. We will offer quite complex HTML forms (game data, source infos, upload files), so the user must be able to save the game data from the current contribution. Therefore we need an implemented game data model - and not a second one, but the only one. A "moderator" has to take a look at the contribution data bevore he can approve it. Or only some parts of it. For all these things I want to build just one integrated data model - not two seperated.
I have in fact done some thinking and research on this problem before making my suggestions. See for example this. To summarize the results of my consideration and research, for having a change moderation system, we have essentially three options:
  • Store all unapproved changes as extra rows in the regular table. Add columns to show the state of each row as either approved or in some stage of the contribution process. Remove old rows from the table when new ones are approved or else have a marker for deprecated rows. I didn't like this idea very well--seems ugly and inelegant and requires us to be quite careful to make sure we're tracking state correctly.
  • Duplicate every table so as to have 'pending' tables, and copy data over when approved. This is a lot like the first method, but I like it a little better--the logical separation should make things simpler.
  • Invent a simple language to describe changes to database tables, and create a single new table to hold all pending changes. If we were sending changes over HTTP as JSON anyway, we don't even have to invent a new language--just store some metadata and the JSON data we'd be sending, and then send it over once approved. This was my preferred method, which led to my suggestion.
gene wrote:For maintenance purposes we may always use HTTP techniques - just add a new server instance and then turn of the old one - like a load balancing server. One may divide an application into two applications for that - if there were no other reasons for not doing this. But I think there are reasons why we should not make two applications.

Do you still want to convince me? :roll:
Well, like I said, I've spent enough words trying to convince you, and I don't think I'm likely to. You have a preference against splitting programs up, and I have a preference for splitting them up, and I guess neither of us will convince the other to change sides. So, unless this post has caused you to have a change of heart, I guess we should just consider this a rejected proposal and be done with it.

The next step, I think, must be to decide how we're storing the unapproved changes. I outlined my thoughts above, but maybe you have a better plan. I'm sure that we should have a new thread for these discussions--I'll leave it to you to create it, if you will.
 #37718  by gene
 08 Dec 2013, 20:35
Tracy Poff wrote:Well, like I said, I've spent enough words trying to convince you, and I don't think I'm likely to. You have a preference against splitting programs up, and I have a preference for splitting them up, and I guess neither of us will convince the other to change sides. So, unless this post has caused you to have a change of heart, I guess we should just consider this a rejected proposal and be done with it.

The next step, I think, must be to decide how we're storing the unapproved changes. I outlined my thoughts above, but maybe you have a better plan. I'm sure that we should have a new thread for these discussions--I'll leave it to you to create it, if you will.
Thanks for your detailed responses and for this fair summary.
I think that the main reason for our different opinions lies in the uncertainty about the contribution process, which you already mention.
Therefore it will be very important that we design the contribution process "perfectly". Your research was a good start (I really like that stackoverflow question you found!) and I have some thoughts in mind. It will take some time until I can start to write them down, but I will definitively do so when I have the time.

Back on topic:
We should keep your proposal in mind. That's of course easy to say, but I really mean it. If our contribution process is designed (and approved by us), we could go back to this point and think about your proposal again. Meanwhile we might also go on with the basic implementation of our data model.