it is down again!
But Dan Lynn is not responding to me. I do not wish to offend him. He
served well, long time.
Could we do something with it in the mid or long term?
- - - -
I would like to have the backup of database of bots, so I could built
more reliable service.
My idea is that I will create service with compatible API, even maybe
with synchronization to robocoderepository.com.
Something like mirror, but more reliable. So it will be up to user to
choose which service he will use.
I will use Google App Engine to implement that.
This will save me from issues with hosting, traffic, database, etc.
http://googleappengine.blogspot.com/2008/05/announcing-open-signups-expected.html
Already have account and went thru tutorial ;-)
Ok, I know, too many balls in the air to juggle for me.
I just wanted you to know my plan for year 2021 ;-)
- - - -
Seriously, I see it as major issue for our users. What priority you
will give it?
Do you have some better idea how to solve it ?
What key features should new design have ?
Pavel
> I would like to have the backup of database of bots, so I could built
> more reliable service.
<snip>
> - - - -
> Seriously, I see it as major issue for our users. What priority you
> will give it?
> Do you have some better idea how to solve it ?
> What key features should new design have ?
Well, one note, is that David Alves (wiki member and author of the
high ranking bot Phoenix) once started working what was meant to be a
combined bot repository and roborumble server, but from what I can see
that project is currently stale.
(See http://robowiki.net/cgi-bin/robowiki?Roborumble.org and
http://roborumble.org for more information about that project)
Ideally, I'd personally like to see something similar (or work on it
resumed), that combines the bot repository, roborumble server, and then
perhaps eventually even becomes a RoboResearch server. If you haven't
seen it already, RoboResearch is a a tool made by Simonton (wiki member
and bot author) made for testing a robot against a series of
reference robots in an automated way. It has been discussed that a
future generation of RoboResearch be possible to run distributed over
the internet similar to the roborumble.
(See http://robowiki.net/cgi-bin/robowiki?RoboResearch and
http://sourceforge.net/projects/roboresearch for more
information about RoboResearch)
Perhaps this is a bit lofty, but personally I think it would be really
nice if we had repository, rumble, and research (3 Rs!) manageable from
a single server. I might be able to try investing some time myself
helping with this if we get a clear plan.
Alex Schultz
I opened the discussion not because I would like to create my own
solution, but because I'm unhappy with currerent robot repository. So
I welcome your effort.
Could you please share with us your current plan, status of the work
and time estimates?
Few my ideas to share. (You may assume that I don't know anything
about subject ;-)
I would like to assure that future repository of robocode robots will
be really open and reliable. So I propose:
- could you create some project at sourceforge to host sources of the
web server? I will join you there to watch, consult and maybe help ;-)
Alex also signaled that he may help.
- the site should allow for download of whole database, so that people
could have backup and/or all robots at once
- the site should allow replication or mirroring. We should discuss
it, to have good plan.
- could we have some REST or SOAP API for the database on roborumble.org ?
We may want to redirect RR@Home traffic to new site.
Could someone invite PEZ or Pulzar or whoever is owner of RR server to
this discussion ?
What are the features that the server should have for contoling RR@Home ?
Could we reuse current solution ?
Is your plan to also takeover the control of battles of RR@Home ?
Database: does anyone have backup of database of robots to upload it
to roborumble.org ?
Does anyone know Dan Lynn well enough to convince him to cooperate ?
Reliability questions:
- do you pay for traffic on the server or for the hosting ?
- how big trafic we may expect ?
- why robocoderepository.com is so unreliable ? Is there some risk ?
- are you willing to share access rights to the server (with someone
else you trust) to be able to do recovery when you are too busy or on
vacations ?
Thanks Pavel
> Competition is a good thing.
>
> I'm gonna refresh the robocoderepository site anyways. It's a fun side
> project for me.
>
> I am quite busy with paid projects. However, I have been dedicating about
> an average of 8 hours a week on getting the new site up. If you've been in
> touch with Flemming, I'm sure he has probably said something about us being
> in contact regarding details and issues several times a week. I assure you
> that I am making progress and have not given up or paused the effort at all.
> I urge you to talk with Flemming and get a feel for how he perceives my
> progress on the new site is coming. I have shared most of the design and
> features with him. It may appear that nothing has been worked on - but this
> is the wrong impression.
>
> However, my focus has been lately on doing a full blown site at launch
> rather than the stripped-down bare essentials site that I was going to hurry
> out the door. Perhaps, I should switch focus back. I think that might be a
> very good idea.
>
> I just finished up some code this weekend that will allow for rewriting the
> bot and team JARs on the fly to insert UUIDs on old-format JARs. It will
> also insert some fields to enable auto-tracking of bot inheritance and to
> facilitate automated uploading of updated bots. Also, initial uploads of
> bots will automagically fill out many of the bot detail fields
> automatically. This same JAR interaction code is being used to re-instate
> all the bot detail records that were lost a while back. Unfortunately the
> data center outage this weekend prevented me from testing and then executing
> the re-instatement.
>
> The new site is very webservice focused. It will be easy for you to
> interact with the repository in any way you like - including fully
> synchronizing your own repository. The webservices might not be fully
> functional on launch since I'm deciding to switch back to doing a bare-bones
> initial launch. This initial launch will actually have more functionality
> than the current site.
>
> After I get the site launched. I will open up the repository source
> (probably at github: http://github.com/). I will welcome help on the site.
> It is a ruby on rails site. I will at least initially act as the final
> reviewer of site changes before pushing to production. As my trust in the
> abilities of others becomes validated, I will be happy to allow others to
> share in this responsibility.
>
> I'm also being intensely pressured to get this site switched over by my
> hosting service since the current site is causing some issues on the server
> due to the old code's interactions with updated services that it was not
> originally designed for.
>
> Please feel free to work on a competitive site. But, keep in mind that I am
> actually making good progress on the new site.
>
>
> See ya,
> Danno!
> Perhaps we will need to modify this validation process to support the
> newer groovy, .net, ruby, etc. based bots. Do we have good validation
> rules for each of these new bot formats?
It would be nice to agree some names of supported robot types as
pointed out by Maciej.
I would prefer to use standard java naming conventions including namespace like
net.sf.robocode.java.1.5 (this is about JRE required)
net.sf.robocode.scala.2.7.1
net.sf.robocode.groovy.1.5
net.sf.robocode.dotnet.2.0
net.sf.robocode.robocodesg.1.0
net.sf.robocode.fancy.robot.math.library.0.1
It should be list not single item as robot might need more of them.
It should also state which version of robocode is required.
- - - - -
.NET robots will be in form of .DLL. It could be bundled into zip.
It could also contain .properties file. (But properties may be also
compiled into DLL in form of assembly attributes.)
For other languages compiled to Java bytecode, I assume no difference.
I foresee pure dynamic robots in form of only single file source code
(for example groovy.) We will provide groovy friendly base classes and
robocode plugin which will handle execution of such robot. There will
be no user java code. (Actually we could do it for Java as well, that
robot will be compiled from single file in engine by jikes). It could
be packed usual way in zip with properties.
- - - -
Overall we are not far enough to tell you more now. As I see it we
need to do language extensions as modules. To have modules we need lot
of work which we are already working on.
It would be great if your new open-sourced site/engine could also
provide extension point, so that in the future your engine could be
extended by another language easily.
See you
Pavel
>> Perhaps we will need to modify this validation process to support the
>> newer groovy, .net, ruby, etc. based bots. Do we have good validation
>> rules for each of these new bot formats?
>
> It would be nice to agree some names of supported robot types as
> pointed out by Maciej.
> I would prefer to use standard java naming conventions including namespace like
>
> net.sf.robocode.java.1.5 (this is about JRE required)
[examples cut]
And if we decide on using OSGi this is already standardized as entries in
manifest file, like (modified from Scala Eclipse OSGi-based plugin):
Bundle-Name: Scala Plugin
Bundle-SymbolicName: ch.epfl.lamp.sdt.core;singleton:=true
Bundle-Version: 2.7.1.r14915-b20080506010100
Eclipse-LazyStart: true
Require-Bundle: org.eclipse.core.runtime; version=3.1.2
*Maybe* we could treat robots as OSGi bundles too, but I'd agree with
Pavel, it's definitely too early to decide.
> I foresee pure dynamic robots in form of only single file source code
> (for example groovy.) We will provide groovy friendly base classes and
> robocode plugin which will handle execution of such robot. There will
> be no user java code. (Actually we could do it for Java as well, that
> robot will be compiled from single file in engine by jikes). It could
> be packed usual way in zip with properties.
Exactly.
Maciej Hrynczyszyn,
Even OSGI in .NET is pain. .NET can't unload modules easily.
http://www-adele.imag.fr/Les.Publications/intConferences/CCNC2006Esc.pdf
So , 90% OSGI is blocker for .NET Robocode. I don't like that direction ;-)