Here is the first design doc draft of AFS
http://www.darkstars.co.uk/randomfiles/AFSdesign.odt
AFS design documents
Moderator: Moderators
Language is a non-issue, but knowing AF it will probably be Java. Guess that Java, C#, C++ (with proper libraries, because c++ stdlib is poor) and even Python would be good choices. In the end, it doesn't really matter.
What matters is protocol. I like the genericness of it, but I hope that nested tables for forming tree structures will be available (that is, UPD table.table.table.key, etc., like in SNMP or LDAP.) I hope I understand correctly that tables will be used for storing information about hosted games e.g.
Also, access control seems a little bit weird (chmod for commands? chmod is bad and limited.) Better use ACLs, they make a lot more sense in command context. If that's what you meant, spell it right, chmod is something very specific.
What matters is protocol. I like the genericness of it, but I hope that nested tables for forming tree structures will be available (that is, UPD table.table.table.key, etc., like in SNMP or LDAP.) I hope I understand correctly that tables will be used for storing information about hosted games e.g.
Also, access control seems a little bit weird (chmod for commands? chmod is bad and limited.) Better use ACLs, they make a lot more sense in command context. If that's what you meant, spell it right, chmod is something very specific.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
I read it, feedback is included.
ODT
(And PDF for the odf handicapped but it lacks the notes inside the document so use the odt.)
In general it's quite hard to read as you skip on parts of the explanation, you need to focus on you readers. They don't already know what you know.
If you make assumptions about what they already should know you need to list it at the top of the document.
I gave it a more structured layout so you can reference parts of the document that describe something in more detail.
Another more general remark would be to dedicate more text to the "why", explain the why X is good.
Once you give the document some more work I can actually give some solid feedback on the suggestions you make in it, I'm not going to do that now as there are to many lose ends that I have to fill in and assume.
I like to have it all explained to me inside the document.
ODT
(And PDF for the odf handicapped but it lacks the notes inside the document so use the odt.)
In general it's quite hard to read as you skip on parts of the explanation, you need to focus on you readers. They don't already know what you know.
If you make assumptions about what they already should know you need to list it at the top of the document.
I gave it a more structured layout so you can reference parts of the document that describe something in more detail.
Another more general remark would be to dedicate more text to the "why", explain the why X is good.
Once you give the document some more work I can actually give some solid feedback on the suggestions you make in it, I'm not going to do that now as there are to many lose ends that I have to fill in and assume.
I like to have it all explained to me inside the document.
The third category of user is the schmuck, the schloob, the normal user. AF's use of language has never been his strong point.
I like the concept, but how are you going to switch between engines and servers dynamically? Could I have the english lobby front end and the chinese one open in tabs?
Java does have a high overhead, what are you going to use? If it is Java, just make optimization your superpriority and know that you'll need to spend more time inserting each module.
I like the concept, but how are you going to switch between engines and servers dynamically? Could I have the english lobby front end and the chinese one open in tabs?
Java does have a high overhead, what are you going to use? If it is Java, just make optimization your superpriority and know that you'll need to spend more time inserting each module.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
I know AF has some difficulty with writing documentation, that's why I'm spending my time writing feedback.
Another general remark, don't spend much time on the implementation details, communicate the overall idea first. You need agreement about the idea to build one lobby for all engine and projects before you should detail its implementation.
Another general remark, don't spend much time on the implementation details, communicate the overall idea first. You need agreement about the idea to build one lobby for all engine and projects before you should detail its implementation.
Yes Java, and yes table.table.key.
And yes, quite a while ago I tried to work with iamacup, and in response iamacup attacked cookiebot and started mouthing of at me in the lobby. However I think that workign with iamacup even if that hadnt happened would be out of the question, ever since he started his C# project he's been increasingly hostile towards me and recently evicted me from his servers.
As for ACLs, Im not familiar with that phrase, unless your talking about key components of AOL 9.0.
The diea with access controls was that you could give basic read write type access control for a user or usergroup so say a user could be given partiol moderator powers in a channel, or bog standard users arent allowed to see who is in a channel, or some user isnt allowed to use a galactic warfare game.
And yes, quite a while ago I tried to work with iamacup, and in response iamacup attacked cookiebot and started mouthing of at me in the lobby. However I think that workign with iamacup even if that hadnt happened would be out of the question, ever since he started his C# project he's been increasingly hostile towards me and recently evicted me from his servers.
As for ACLs, Im not familiar with that phrase, unless your talking about key components of AOL 9.0.
The diea with access controls was that you could give basic read write type access control for a user or usergroup so say a user could be given partiol moderator powers in a channel, or bog standard users arent allowed to see who is in a channel, or some user isnt allowed to use a galactic warfare game.
ACL = access control list. You could attach them to everything, be it a command or a channel or a table or a key or whatever. See SELinux or (surprise!) Windows file access privileges for examples.
PS. in case you miss a important link in that article: http://en.wikipedia.org/wiki/Role-based_access_control
PS. in case you miss a important link in that article: http://en.wikipedia.org/wiki/Role-based_access_control
http://www.darkstars.co.uk/randomfiles/ ... Draft2.odt
http://www.darkstars.co.uk/randomfiles/ ... Draft2.pdf
Ignore the notes tim left, they dont apply any longer as I changed the text but I dunno howto remove them.
http://www.darkstars.co.uk/randomfiles/ ... Draft2.pdf
Ignore the notes tim left, they dont apply any longer as I changed the text but I dunno howto remove them.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
I'm presuming you use Open Office:
Disable recording of changes in edit->changes->record (translated from Dutch)
Then use the "navigator" (F5 while having OO.o active) to select a note and then press delete on your keyboard.
Then re-enable recoding of changes if you like to use it.
Another remark real quick, the title is bla. bla. draf 2 with feedback from Tim Blokdijk.
I gave feedback on draft 1 so you can better remove something like that.
You should have a table at the end of the document to list the changes between drafts there you can credit people that gave feedback.
I will comment on draft 2 and include such a table.
Disable recording of changes in edit->changes->record (translated from Dutch)
Then use the "navigator" (F5 while having OO.o active) to select a note and then press delete on your keyboard.
Then re-enable recoding of changes if you like to use it.
Another remark real quick, the title is bla. bla. draf 2 with feedback from Tim Blokdijk.
I gave feedback on draft 1 so you can better remove something like that.
You should have a table at the end of the document to list the changes between drafts there you can credit people that gave feedback.
I will comment on draft 2 and include such a table.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Note that I want to discuss things like moderation, administration, and user account management in another document.
Also I'm curious about integrating an existing IRC server complete with its connection code and just integrate user accounts and so on with the server for tasclient compatability, so that I can discount IRC client detection from the whole protocol differentiation thing.
Also I think perhaps each module subsystem should be able to define its protocol independently of the server beyond the basic table + MSG and username commandset, and that the design fo the sub systems should rflect that.
Also I'm curious about integrating an existing IRC server complete with its connection code and just integrate user accounts and so on with the server for tasclient compatability, so that I can discount IRC client detection from the whole protocol differentiation thing.
Also I think perhaps each module subsystem should be able to define its protocol independently of the server beyond the basic table + MSG and username commandset, and that the design fo the sub systems should rflect that.
I have done some work and have a basic featureset implemented. I will upload AFS alpha 0.00001 in a few moments, there are some things that need discussing regarding implementation of tables and security.
Here is the implemented protocol:
MSG AFS LOSTUSR username - A user (username) timedout or the connection was lost
MSG AFS RMVUSER username - same as above only the user exited correctly using MSG AFS EXIT
MSG AFS EXIT - Sent to the server to logout and disconnect
MSG AFS PING xyz - sent to the server, anything after PING e.g. xyz is used as an identifier. The message is sent back as is to the sender by the server.
MSG AFS STOPSERVER - stops the server, not sure if it works, the quickserver admin interface would be a better method of doing this
MSG ALL data - Broadcasts a message to all users of the format "MSG user data" where user is the username of the broadcasting client
MSG username data - If sent to the server the username field is the destination user of the message. The username field is then replaced with that of the sender and forwarded to the destination.
MSG username data - If recieved from the server, user is the user who sent you the message and data is the data theyre sending
PUT key=value - Puts a key value pair to the server to be stored Aside from "VALUE " this message is seperated by the '=' in the middle allowing keys with spaces. The server then sends the same message out to all users notifying them of the change
GET key - Sent to the server to retrieve a keys value. Aside from "GET " this message has no seperators allowing keys with spaces.
VALUE key=value - returned by the server declaring a key has a certain value. Aside from "VALUE " this message is seperated by the '=' in the middle allowing keys with spaces.
RMV key - sent to the server to remove a key value pair. The server then sends the same message out to all users notifying them of the change
Here is the implemented protocol:
MSG AFS LOSTUSR username - A user (username) timedout or the connection was lost
MSG AFS RMVUSER username - same as above only the user exited correctly using MSG AFS EXIT
MSG AFS EXIT - Sent to the server to logout and disconnect
MSG AFS PING xyz - sent to the server, anything after PING e.g. xyz is used as an identifier. The message is sent back as is to the sender by the server.
MSG AFS STOPSERVER - stops the server, not sure if it works, the quickserver admin interface would be a better method of doing this
MSG ALL data - Broadcasts a message to all users of the format "MSG user data" where user is the username of the broadcasting client
MSG username data - If sent to the server the username field is the destination user of the message. The username field is then replaced with that of the sender and forwarded to the destination.
MSG username data - If recieved from the server, user is the user who sent you the message and data is the data theyre sending
PUT key=value - Puts a key value pair to the server to be stored Aside from "VALUE " this message is seperated by the '=' in the middle allowing keys with spaces. The server then sends the same message out to all users notifying them of the change
GET key - Sent to the server to retrieve a keys value. Aside from "GET " this message has no seperators allowing keys with spaces.
VALUE key=value - returned by the server declaring a key has a certain value. Aside from "VALUE " this message is seperated by the '=' in the middle allowing keys with spaces.
RMV key - sent to the server to remove a key value pair. The server then sends the same message out to all users notifying them of the change
May I suggest (depending on what semantics do you plan for GET table):AF wrote:GET key - Sent to the server to retrieve a keys value. Aside from "GET " this message has no seperators allowing keys with spaces.
VALUE key=value - returned by the server declaring a key has a certain value. Aside from "VALUE " this message is seperated by the '=' in the middle allowing keys with spaces.
GETNEXT table.|key - Sent to the server to retrieve a keys after a given key value. If only a table name is provided, key returned is first in order. (note the dot after table.)
Example why it's useful:
Code: Select all
-> GETNEXT channels.
<- VALUE main=<table>
-> GETNEXT channels.main
<- VALUE aflobby=<table>
-> GETNEXT channels.aflobby
<- VALUE lua=<table>
...Indeed, GETNEXT also has a fatal flaw in that it assumes the table wont change before the client reaches the end.
Instead a LIST command may be more appropriate. AFS already sends out new values as the key value pairs are changed added or removed.
I think that the table system will ned a little thought and restriction. I need to be able to store it in a mysql database.
Instead a LIST command may be more appropriate. AFS already sends out new values as the key value pairs are changed added or removed.
I think that the table system will ned a little thought and restriction. I need to be able to store it in a mysql database.
That's impossible to guarantee in GET, too, it's just a lot less likely to be noticed. Your design already includes notifications by the server that tables changed, I don't see a reason not to use them.AF wrote:Indeed, GETNEXT also has a fatal flaw in that it assumes the table wont change before the client reaches the end.
I agree that there's a lot to think about. I'd look at some existing protocols for inspiration. GETNEXT in particular is taken straight from SNMP, which your protocol strongly resembles.