It fitsq quite well the requirements of 1.0 specification.
The client can run disconnected from the server (it assumes the old list is correct and works with it). Also, it only uses HTTP protocol to download/upload files, and that should prevent some security/firewall issues.
Once the results are uploaded, a server should be set up to calculate the rankings.
I expect to finish it during this week. I'w upload the source code when I have it ready.
Question for PEZ: Can we use this server to upload the bots into it? May be could be a good idea to have a common user and password with access to a single directory to upload the bots.
Another point: The Wiki would be perfect to maintain the participants list. I'w create a page for it. If you want to include your bot, feel free to do it (be careful with the syntax):
For sure I'w need it. I'm releasing this first version so we have a guiding architecture and people can develop each part further. I'w need help also with the server side (I have no knowledge at all about servlets, jsp, etc). The idea is that the client would post the results using a Web form, but I'w not be able to develop it. -- Albert
If the data is sent through HTTP in a text sort of format, I can also help with that, using something as basic as Perl (which obviously exists already on this server). I also know how to send raw post data to a server-side script from Java, if there is anything you haven't figured out yet. -- Kawigi
We have several options for the server side. Were can I read about what the server should do? I and Jim (and I now see Kawigi too) can look into how to setup the framework for this. I think using a web form is a good way to go. The Java API should have some classes and methods for this that we can use in the client. But otherwise tools like HTTPUnit could be used. Sure this server could be used to upload the bots to. But I wonder why we don't use the RobocodeRepository for this? All bots are uploaded there as it is anyway. If the repository closes we can always reconsider. -- PEZ
I tried to download them from the RobocodeRepository, but for some strange reason the connection gets refused :-( Anyway, I'w soon download the code so people can check why it's not connecting to the RobocodeRepository. -- Albert
I tried, but I'm unable to follow it ... has somebody checked it already? May be it could become a priority task. -- Albert
This is mega-exciting! When you read the particpants list, please use the URL http://robowiki.dyndns.org/?RoboRumble/Participants rather than http://robowiki.dyndns.org/perl/robowiki?RoboRumble/Participants since the latter might stop to work. -- PEZ
Ok, we seem to have the client side working reasonably well. Is there any progress on the server? If there is anything i can do to help, let me know, but understand that i have limited programming knowledge, and almost no java knowledge. -- Tango
Cool. I'w start building the upload result part of the application. It will use the POST method to pass the results in the URL. May be someone could start thinking how to store and retrieve the results from the server? -- Albert
PEZ, Any chance you could put Tomcat on the wiki server and configure it? If you can do that, I can write the server side of this. Other wise this is going to take some form of a perl app and I am not profecient enough to do that. -- jim
Albert, maybe you could consider packaging the results as an XML-file and post it as the contents of a form? That way we will have the results in a reasonable format to start with on the server side and lots of standard tools at hand for transforming and traversing or whatever with the data.
Jim. I think I already have Tomcat installed. I will check it and install it if not. I would like the full solution to be Java. Just to honour the choice of deployment platform for Robocode itself if for no other reason. You can go on writing the servlet and/or JSP pages or whatever (How about we use Struts? That way we get lots of help from that framework to separate presentation, logic and data and a host of tag libs and such as well.) and we can install the webapp here when you have a test version. Someone know their Ant good enough to make a war-deployment script? -- PEZ
If you get the results on the server in some kind of database, like MySQL? (or something simpler if you like), then you should be able to convert the results to XML. If you use the same XML as roboleague (for consistancy) i will start writing some XSLT to display it. -- Tango
Ok, i've got some very simple xslt you can use for testing when you get to that bit. PEZ, you're the one that need to do something to let me upload it somewhere, yes? If so, can you please do whatever it is you need to do. Thanks. -- Tango
Well, I have no idea on XML, so I better upload the results using an URL and let the server side to convert it :-( Albert
I would agree. You don't want to store data in XML anyway, you want a database for that. It is much easier to just send it in a URL, let the server put it in the database, and then somehow convert it to XML to display (i have no idea how to do that, i only know the last bit with the XSLT) -- Tango
Results upload format
I'w upload the results using the following URL:
http://theserver/thepage?game=roborumble&rounds=10&field=800x600&user=USERID&time=1062015727040&fname=apv.Aspid 1.7&fscore=1000&fbulletd=500&fsurvival=6&sname=apv.MicroAspid 1.6&sscore=999&sbulletd=490&ssurvival=4
Sounds good to me. You might want to add something later for security. Some kind of algorithum based on the url with the result on the end of the url. ASCII numbers of each charecter added together with something secret done to them, or something. I recommend something involving modular maths, as it is supposed to be hard to work out or something, i don't really understand it, but RSA ciphers use it, so it must be good, (if it works in this situation). -- Tango
Shouldn't we pick something more extensible? This way we won't be able to upload melee results.
notice the version for future expansion, the 2 indicating two result-lines, and the discarding of superfluous labels (This should keep us from hitting the max-GET length).
Another option is POSTing a serialized (XML?) form of the results or using RMI ...
I don't really know. Who knows anything about databases? We should upload the results in a way that helps with that. -- Tango
OK, I'w add the version so we can extend it later to melee. I'w keep the field names, because I think we are far away from max-length and it will make things easier in the server side. About using RMI, I think is better to use HTTP protocol, because it will create less security issues and will not interfere with firewalls (I think RMI uses diferent ports?). To be honest, any system seems OK to me, but the most important thing right now it to get it done (So if somebody wants to develop the XML+server side... go for it). I'w keep going in the direction of passing the data in the URL (it's the only way I'm able to implement) and would be nice somestarts working in the server. -- Albert
Just using the URL seems simplist. Simple is usually good. -- Tango
The most obvious place to look for restrictions of the length of a URL request would be in the internet RFC defining the protocol(s) in question. For HTTP 1.1 this is RFC 2068. ([here]). The RFC does not explicitly limit the length of the URL to anything -- ie, as defined by 2068, the length of a URL is unbounded. There is a suggestion made in section 3.2.1 that some proxy servers limit the length of the URL to 255 characters.
Albert's string was already 213 characters long. We might get into trouble with some proxies.
That must be the super-clean not-doing-anything-implicitly version. My version would be more like this:
URLConnection conn = (new URL("URL goes here")).openConnection(); conn.setDoOutput(true); PrintWriter out = new PrintWriter(new OutputStreamWriter(conn.getOutputStream())); out.println("param=value¶m=value¶m=value, etc... The encoding is all done automatically"); out.flush(); out.close(); BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream())); String result = in.readLine(); //parse information from script in result, may even be several lines (this only gets the first) in.close();
OK, the we will POST the results. But I insist, the first thing we need is ANY server side uploading the results, and I can't do it. -- Albert
Given the input that will be sent, I could give it a shot. It doesn't even necessarily need to be in the param=value¶m2=value2 format or anything, either, that's just how it's sent from web-forms. -- Kawigi
If you like a test that you can post data to a http server you could always use a wiki page I think. A URL like: http://robowiki.dyndns.org/perl/robowiki?action=edit&id=RoboRumble/ResultsPostingTest would do the trick. If you place the data inside <pre></pre> tags it should also be quite readable. For anyone who like to experiment with a server side agent you can always install Tomcat locally and get Roborumble to post to your local Tomcat. I'll go do that check now if I have Tomcat on the server or not. -- PEZ
OK, I managed to install Tomcat in my computer, so I can start developing the server side now. I got some examples and doesn't seems complicated. -- Albert