So the question is: should we develop the socket server (and decide our own non-standard communication format) or use the industry standard for communication?
Think future. Right now, JDK 1.1 might give us better compatibility, but in 1 or 2 years everyone will have updated. Look at the white wolf forums, they were OK on it's time but now they're obsolete. I don't think we need to give that feeling to our players if this project keeps going. And the compatibility issues can be dealt by simply adding a link to the update files (or even checking the client version and redirecting to the new one if their java is obsolete).
The SOAP way opens a lot of possibilities, like allowing users to access some of the methods in order to keep their fan-pages updated in real time, or sending RSS feeds to instantly give news like xp distribution, updates or something.
Also, SOAP in this project could give more power to the business logic layer, with more elegant interaction between the Java UI and the database.
I suggest we go with the newest technology and leave legacy behind. Think about it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not really convinced about whether we need something like SOAP. What advantages does it give us over piping serialized Java objects over socket connections? I would prefer an answer different from "but it has XML!" ;).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And *why* are we using .net? Do we really need to get on web services bandwagon if what we make is a beefed up IRC server? Would you please be so kind and explain me what kind of programming tasks will .net XML services simplify for us?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main part about using .net is... that I suck at Java and don't have time to learn better. When we started the recruiting, there were a couple other .net developers around there, so it seemed like a good idea, simply to get more manpower on the project.
Actually what we are trying to do is a lot more than an IRC server, it's really close to some of the earlier online videogames if you think about it. We are even doing our own graphics engine lol.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand the reasons for which you prefer .net, but there are quite a few drawbacks there, too (for instance vendor lock-in or maturity issues). Java is quite similar to .net anyway, so why don't we go with a single language to rule both client and server? That should save us quite a lot of headache with those super-duper-abstract XML protocols that stuff enough crap onto a single message to make it strangle a dialup line (did you see just how much stuff does a simple "hello world" SOAP message have inside?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all. I want to make a point that the communication method has very little to do with why White Wolf chats is outdated. I think the reason White Wolf chats are outdated is because they used a standardized chat program (digichat), instead of making something homebrew which they could edit and program on. As for communication, Alankor, you are the team leader of this part. I have heard there are some good advanatages to using XML webservices, but this is not more forte. My primary concerns are:
- Easy of programming
- Compatability and not requiring users to download much
- Performances and actual benefit from whatever communication method we use
- Lastly, I expect abstraction so that our communication method can be switched out with another IF it becomes absolutely necessary. Abstract is always good =P Long live 00P.
- Daedius
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, i'm spanish and my english is not as good as it should be... what does vendor lock-in mean?
I can't see the maturity issues. .net code isn't buggy and works well (when it's well written). If there were any bugs within the framework, they get updated without forcing us to change even 1 line of code, so it's ok.
Now, I see why you care about this, didn't think that the character sheet had THAT many records (for VTR it can get 9 upperboxes, 9 attributes, 24 skills, 9 merits, 3-9 flaws, 10 disciplines, humanity up to 10, blood potency, health, vitae and willpower, and then the inventory, totalling almost 100 records in the worst case scenario). Please help me think this out a little since I'm excessively enthusiast with new technologies.
First, I'll tell you how I think we can do the data model:
All the upper section of the character sheet is stored under the same class, UpperBox. It keeps properties for the caption (the label that is left of the field) and the value (what the user fills in).
All traits (attributes, skills, merits, health, morality... everything) are stored under traits class.
All inventory items (weapons, items, general posessions like cars or houses)are stored under the InventoryItem class
We don't store empty values. If you have 0 in academicism, we don't keep that. If you are a human, we don't store your "clan", and if you didn't have health levels, then we don't store that either. That allows me to save some space, but makes character objects of variable weight in kb.
Then, let's describe the problem:
The full character sheet in the worst case scenario stays at 34 kb. With a more common character, with 35 different traits and such it's 16 kb.
Now let's see what this means for the server:
Supposing 100 simultaneous users trying to download it at the same time, this takes 3.4 Mb of bandwith (worst case) or 1.6 Mb (common case). That's not much for a standard server pipe, and we won't be getting 100 simultaneous requests i guess.
From client side:
A standard dial-up modem, on a common day downloads at 3-4 kb, 6 at best. Let's give it 3.5.
For our worst-case, we have a 10 second download time (a lot, i know). For best case, it goes down to 5. For ISDN and DSL (really common right now) this sizes are not a problem, but let's think everyone has dial-up or downloads a lot of porn so the eMule takes all their bandwith away.
This means watching a progressbar for 5-10 seconds while they change characters. It's not much, but it can get serious
Now, the possible solutions I see so far:
1 - Streaming. It's easy to send text as a stream to the client. Since the character probably won't start rolling on it's first 10 seconds into play, then we won't have any problem. If the character starts by looking up at his character sheet, the UI could make it be filled as soon as the data arrives, it might be cool to make it look as it's gradually filled in.
2 - Custom XML. I already have done an object for another project that serializes any object into standard XML (not SOAP), through reflection, and it can serialize our character sheet in 10 kb worst case. It also allows for "easier to read" (for human eyes, not machine) XML, and that might be an advantage. Also, to avoid coding our own socket server to handle communications, can we make the client read our custom XML from server hard disk instead of sending it through sockets? Well, probably we could even make this binary so it takes even less bandwith, but I don't like it that much because it's less abstract.
3 - Going Java. If we do this, then I wouldn't be of much help. Maybe I could build the MySQL database, or I could send you the objects I build in .net so you can translate them to Java. This is the solution I like worst
Kinda long for a forum post, but I needed to make everything as clear as possible. Feel free to add new possibilities or anything.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding XML size: Hmmm, I wonder if we can gzip the data that server transfers to clients. Things like XML are going to be squished quite a lot, won't they? Can you check how big are your XML objects after being gzipped?
Regarding .net: .Net belongs to Microsoft. Microsoft enjoys making their stuff work only with their other stuff. There go our cross-platform ambitions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I googled a little, and it is a great idea to gzip our output! It seems like we will be getting a 60-80% compression rate... so our worst case would go from 34kb to 13.6-6.8 kb which seems really nice for me. (about 4 seconds download for dial-up)
I've never implemented gzip, but I've found a few free libraries that we can use for it, so it should be easy and make for really nice learning. Thanks a lot man.
Hey, since you seem to know a lot about this, will you handle the deserializing part on the UI? You know, receiving the SOAP, unzipping and deserializing into Java objects?
On other topic, .net IS cross-platform. I guess it's a commercial move so they can sell cheaper Mac and Linux software or something. .net works over a virtual machine, just like Java, so it works over any system that develops one. And there is one for linux, the mono project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, discussion is possible ;). gzip is really way to go for XML transfers. However, what advantages does SOAP give us over piping gzipped XML here and there?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most objects can deserialize with no more than 3 lines of code, and *everyone* understands SOAP. This allows us to work against almost any possible modern database or programming language in the world, and since it seems to be what all industry is heading for, we will probably be getting more and more support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Java doesn't get along well with XML web services, but it really isn't so since JDK 1.3 if you download apache soap client.
http://www.apache.org/dyn/closer.cgi/ws/soap/
So the question is: should we develop the socket server (and decide our own non-standard communication format) or use the industry standard for communication?
Think future. Right now, JDK 1.1 might give us better compatibility, but in 1 or 2 years everyone will have updated. Look at the white wolf forums, they were OK on it's time but now they're obsolete. I don't think we need to give that feeling to our players if this project keeps going. And the compatibility issues can be dealt by simply adding a link to the update files (or even checking the client version and redirecting to the new one if their java is obsolete).
The SOAP way opens a lot of possibilities, like allowing users to access some of the methods in order to keep their fan-pages updated in real time, or sending RSS feeds to instantly give news like xp distribution, updates or something.
Also, SOAP in this project could give more power to the business logic layer, with more elegant interaction between the Java UI and the database.
I suggest we go with the newest technology and leave legacy behind. Think about it
I am not really convinced about whether we need something like SOAP. What advantages does it give us over piping serialized Java objects over socket connections? I would prefer an answer different from "but it has XML!" ;).
Hm, the thing is we are using .net as backend, so we need something to allow cross language interaction.
And *why* are we using .net? Do we really need to get on web services bandwagon if what we make is a beefed up IRC server? Would you please be so kind and explain me what kind of programming tasks will .net XML services simplify for us?
The main part about using .net is... that I suck at Java and don't have time to learn better. When we started the recruiting, there were a couple other .net developers around there, so it seemed like a good idea, simply to get more manpower on the project.
Actually what we are trying to do is a lot more than an IRC server, it's really close to some of the earlier online videogames if you think about it. We are even doing our own graphics engine lol.
I understand the reasons for which you prefer .net, but there are quite a few drawbacks there, too (for instance vendor lock-in or maturity issues). Java is quite similar to .net anyway, so why don't we go with a single language to rule both client and server? That should save us quite a lot of headache with those super-duper-abstract XML protocols that stuff enough crap onto a single message to make it strangle a dialup line (did you see just how much stuff does a simple "hello world" SOAP message have inside?).
First of all. I want to make a point that the communication method has very little to do with why White Wolf chats is outdated. I think the reason White Wolf chats are outdated is because they used a standardized chat program (digichat), instead of making something homebrew which they could edit and program on. As for communication, Alankor, you are the team leader of this part. I have heard there are some good advanatages to using XML webservices, but this is not more forte. My primary concerns are:
- Easy of programming
- Compatability and not requiring users to download much
- Performances and actual benefit from whatever communication method we use
- Lastly, I expect abstraction so that our communication method can be switched out with another IF it becomes absolutely necessary. Abstract is always good =P Long live 00P.
- Daedius
Sorry, i'm spanish and my english is not as good as it should be... what does vendor lock-in mean?
I can't see the maturity issues. .net code isn't buggy and works well (when it's well written). If there were any bugs within the framework, they get updated without forcing us to change even 1 line of code, so it's ok.
Now, I see why you care about this, didn't think that the character sheet had THAT many records (for VTR it can get 9 upperboxes, 9 attributes, 24 skills, 9 merits, 3-9 flaws, 10 disciplines, humanity up to 10, blood potency, health, vitae and willpower, and then the inventory, totalling almost 100 records in the worst case scenario). Please help me think this out a little since I'm excessively enthusiast with new technologies.
First, I'll tell you how I think we can do the data model:
All the upper section of the character sheet is stored under the same class, UpperBox. It keeps properties for the caption (the label that is left of the field) and the value (what the user fills in).
All traits (attributes, skills, merits, health, morality... everything) are stored under traits class.
All inventory items (weapons, items, general posessions like cars or houses)are stored under the InventoryItem class
We don't store empty values. If you have 0 in academicism, we don't keep that. If you are a human, we don't store your "clan", and if you didn't have health levels, then we don't store that either. That allows me to save some space, but makes character objects of variable weight in kb.
Then, let's describe the problem:
The full character sheet in the worst case scenario stays at 34 kb. With a more common character, with 35 different traits and such it's 16 kb.
Now let's see what this means for the server:
Supposing 100 simultaneous users trying to download it at the same time, this takes 3.4 Mb of bandwith (worst case) or 1.6 Mb (common case). That's not much for a standard server pipe, and we won't be getting 100 simultaneous requests i guess.
From client side:
A standard dial-up modem, on a common day downloads at 3-4 kb, 6 at best. Let's give it 3.5.
For our worst-case, we have a 10 second download time (a lot, i know). For best case, it goes down to 5. For ISDN and DSL (really common right now) this sizes are not a problem, but let's think everyone has dial-up or downloads a lot of porn so the eMule takes all their bandwith away.
This means watching a progressbar for 5-10 seconds while they change characters. It's not much, but it can get serious
Now, the possible solutions I see so far:
1 - Streaming. It's easy to send text as a stream to the client. Since the character probably won't start rolling on it's first 10 seconds into play, then we won't have any problem. If the character starts by looking up at his character sheet, the UI could make it be filled as soon as the data arrives, it might be cool to make it look as it's gradually filled in.
2 - Custom XML. I already have done an object for another project that serializes any object into standard XML (not SOAP), through reflection, and it can serialize our character sheet in 10 kb worst case. It also allows for "easier to read" (for human eyes, not machine) XML, and that might be an advantage. Also, to avoid coding our own socket server to handle communications, can we make the client read our custom XML from server hard disk instead of sending it through sockets? Well, probably we could even make this binary so it takes even less bandwith, but I don't like it that much because it's less abstract.
3 - Going Java. If we do this, then I wouldn't be of much help. Maybe I could build the MySQL database, or I could send you the objects I build in .net so you can translate them to Java. This is the solution I like worst
Kinda long for a forum post, but I needed to make everything as clear as possible. Feel free to add new possibilities or anything.
Regarding XML size: Hmmm, I wonder if we can gzip the data that server transfers to clients. Things like XML are going to be squished quite a lot, won't they? Can you check how big are your XML objects after being gzipped?
Regarding .net: .Net belongs to Microsoft. Microsoft enjoys making their stuff work only with their other stuff. There go our cross-platform ambitions.
OK, I googled a little, and it is a great idea to gzip our output! It seems like we will be getting a 60-80% compression rate... so our worst case would go from 34kb to 13.6-6.8 kb which seems really nice for me. (about 4 seconds download for dial-up)
I've never implemented gzip, but I've found a few free libraries that we can use for it, so it should be easy and make for really nice learning. Thanks a lot man.
Hey, since you seem to know a lot about this, will you handle the deserializing part on the UI? You know, receiving the SOAP, unzipping and deserializing into Java objects?
On other topic, .net IS cross-platform. I guess it's a commercial move so they can sell cheaper Mac and Linux software or something. .net works over a virtual machine, just like Java, so it works over any system that develops one. And there is one for linux, the mono project.
Wow. Check this out. From 68.957 bytes to 4.082. I guess there is no discussion possible. SOAP with gzip is the way to go.
Actually, discussion is possible ;). gzip is really way to go for XML transfers. However, what advantages does SOAP give us over piping gzipped XML here and there?
Standarization and ease of programming.
Most objects can deserialize with no more than 3 lines of code, and *everyone* understands SOAP. This allows us to work against almost any possible modern database or programming language in the world, and since it seems to be what all industry is heading for, we will probably be getting more and more support.