Table of contents |
Here is a roadmap for the project. It should get us started by working through the points from top to bottom. So if you change the order of things, please state your reason. Maybe discussions about the roadmap should be placed near the bottom of this page. The roadmap should be cleaned up from time to time so it's clear and uncluttered.
It should be indicated where in the project we are (i.e., are we still talking about the development method? Are we finalizing the feature wishlist (at least as far as it concerns the first iteration)? Are we already doing use cases?
dnerra: (should this go here?) For the general architecture, jsettlers (
http://sourceforge.net/projects/jsettlers/) might be a comparable project and worth a look to get ideas.
The code license needs to be determined as soon as possible, as this will affect whether or not some people can work on the project.
Benjamin: If we choose a strict license like GPL, we should always keep in mind the possibility to publish single files (e.g. one containing a rating algorithm) under a second license that allows further usage in other (even commercial) programs.
Maybe we should have a short vote where everybody who cares states his preferred licence(s):
Licences to choose from:
This means that the UGS programmers could add an option to client/server to download the full server source code; and anybody building a go server from the UGS sources would not be allowed to remove this option.
Benjamin: When there's such a huge free go-database included, we must have a lot of thoughts about copyright:
Use an agile method (which is responsive to changing requirements) such as extreme programming ( http://www.extremeprogramming.org/). Use iterative development to split up the work into manageable chunks. Release early, release often. Test everything.
Project communication language should be english so that developers from all over the world can join the project.
Christoph Gerlach: Use restrictive conventions for naming, coding and documentation. Build a framework for the implementation and a very thin prototype (maybe only for very simple client/server communications without any Go in it but stressing the full vertical architecture: client-net-server-database) with only a few developers. If this works well and the results are satisfying and promissing, all other developers are welcome to contribute and development can widen. While the basic architecture and the prototype are under development, others can analyse and design (implementation independent) class models for all "objects" in the UGS.
dnerra: I don't think it is necessary to formally restrict this to few developers. However, very few (or even just one) of the more experienced Java programmers could take over a maintainer role, i.e. noone else would check-in their changes without review from one of the maintainers. On the other hand, I would think if anyone would want to start a primitive server prototype (just accepting connections and maybe implementing primitive chat functions), he should go ahead immediately; discussing implementation and working in a group on the code works much better once there is code to talk about.
Christoph Gerlach: Maybe it's not good to start a discussion in this section but I am strongly in favor of "thinking first". Starting with an implementation and then throw away everything later (which is allmost 100% sure if you don't think before about the requirements of the implementation) is frustrating and not productive at all. Also a discussion about "what's so bad about this implementation" is time consuming and frustrating. The first implementation must be a good one. That will stop discussion and fasten the overall development by far. About checking in/review/maintainer: I am not in favor of such a bottleneck. I would suggest to agree on conventions and implementation framework before the real coding starts.
dnerra Well you are certainly more experienced in software development than I am, so let me only comment on the maintainer aspect: I just don't think open source works without some people playing the maintainer role. This needn't be a bottleneck; everybody who has earned trust can just check-in his changes without review. But I don't think enforcing conventions works with new people joining the project etc. and without reviews taking place.
Take existing Go internet and desktop applications as a starting point. Look at the KGS, IGS, NNGS etc. protocols, and look at the GTP.
Describe here.
(Reuven: I'm not sure that there's a real need to replace gobase.org and goproblems.com - If ppl want to change something in them, they probably should try suggesting the changes to the authors first!)
Describe here.
Describe here.
anon? Focus switching and Pop-up windows are often critized, but when you say "It's Java..." then look at
http://java.sun.com/products/jlf/ed2/book/ That's the way the Java Foundation Classes are constructed. And these are not ergonomical in all cases. You can programm around them, but this will add a lot more of work. And it must do at the beginning. Or you will end with the same entries in the wishlist like KGS actually does. (Look at Java-GUI Jago - it has the same problems.) So, Go-ergonomical or Java, that is the question... Anyway - Java as a platform-independent language is surely the best choice.
Benjamin: So do I understand you right that although you support Java in general, you would not use just JFC but instead write something on your own? I'm not too familiar with JFC and its disadvantages, so it would be nice if you go a bit further into detail ^^
What kind of server is this going to be ?
Create UML-style use cases with actors and actions. Typically, actors will be users and the actions can be described in sentences like "A user joins a room", "A user creates a new game". By looking at the verbs and objects of the sentences, you can get an idea of the objects we need to design, and the actions that should be possible with it. For example, from the previous two use cases you see that we have as objects "user", "room", "game". A room has a "join" method. A game has a "create" method. And so on.
From the use cases, determine what objects there are. The goal is to describe the system in business terms, not going into implementation details.
From the OOA, determine an API to access those objects
XML? Plain text?
(Reuven: I'm not sure about it - I like the idea of compressed sgf sequences and such - Maybe it should support both?)
dnerra: I think it is assumed that game results, game records, etc. will be stored in a separate database. What database should be used for this?
Benjamin: Good question. The database should be:
Any suggestions?
dnerra: I would think that pretty much any database will satisfy our needs; so it might make sense to go with the default choice of MySQL as the most widely available open source database?
For each iteration, run through a whole cycle of
Provided by sourceforge.
Ansgar?: What about using
GNU Arch instead of CVS for version control? It supports decentralisized development and better branching/merging, also from other parties. A lot can be done without network connection, because the working responsitory could be stored local and just a mirror on the net. Also remote responsitories can easily be mirrored to the local disk. (for more information have also a look on the
Arch Wiki)
Fwiffo: Also worth mentioning is
subversion (I don't have a preference, but thought I'd throw it out there).
Ansgar?: Subversion requires either Apache2 with WebDAV and a special Subversion-module or a stand-alone server. We would have to find someone else than SourceForge to host this project... Also Subversion is, like CVS, a centralisized system and supports no disconnected operations.
Rakshasa: Subversion does not require apache nor WebDAV, it includes APR in the source. If you want the archive to be accessible by webpages then you need those. Ofcourse it does have a standalone server (unless you tunnel svn through ssh user accounts, not something i'd recommend), but that is true for other repositories.
Ansgar?: Subversion doesn't require Apache on the client, but it does on the server (or you have to use ths stnd-alone server). In contrast, GNU Arch doesn't require any special server (just any httpd), even for read-write access only sftp is sufficent. Also just access over ssh isn't enough for an Free Software project. The source code should be aviable to anyone.
Rakshasa: You pretty much have to use a server of *some* kind, httpd or stand-alone. What does just have access over ssh? Subversion supports: local r/w to the repository, tunneled through ssh, or a stand-alone server that has it's own set of users. The latter only requires that you have a svn client. Also you can have the repository available through an apache module. So, yes, it's available to anyone. And no, it does not hide anything from freedom loving Free Software people.
Ansgar?: Sorry, maybe I didn't say clear enogh what I mean. On SourceForge it isn't possible to setup a stand-alone server or to install an apache module. Thus only ssh-tunneled access would be possible with Subversion on SourceForge (I hope I got that right :-) So only people with ssh-access to SourceForge could use the responsitory which is a strong point against Subversion.
I having used CVS for years, and recently started using SVN for my own project. I would *strongly* recommend SVN, CVS has too many limitations. Can't move or delete directories without manually editing the repository. Revisions are per file on CVS, while SVN has a global revision. Much easier to copy, move and tag files, and you got ls.
Ansgar?: Arch also avoids many of CVS's pitfalls. It has, like SUbversion, whole-tree commits, renaming files and directories is supported (often mv is enough). But GNU Arch also offers history-sensitive merging (a already merged patch from a branch isn't merged again later) and decentralisized development, neither feature is offerd by Subversion.
Rakshasa: Subversion has similar CLI interface as CVS, this is a hugh advantage. Looking at Arch docs it seems a completely different way of working. There's only one GUI client for Arch vs. many for subversion. You don't have anything like tortoisesvn for arch. And as a bonus, it uses centralisized development. (Yes, that is a good thing for a project this size)
Ansgar?: True, Arch tries to implement another (maybe better) VCS, whereas Subversion only tries to be a better CVS and is much more similar to it. Also I think forcing people to do centralisized development has more disadvantages than advantages. Imagine someone (not in the core team, so no r/w access to source responsitory) wants his own branch to try out something new, but also keep track of changes by other developers. The core team could later pick some parts and merge them back into the main line. This isn't possible with neither CVS nor Subversion, but very easy with Arch.
dnerra: Ansgar, I am very familiar with the problems of CVS, and I also know that while Subversions has fixed some of the most annoying shortcomings, it's not a fundamental step forward. But I really doubt Arch is practical for our purposes:
- I suspect we will have developers on Windows; "currently (July 2004) Arch is still far away from Subversion's windows support" (
http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison). Has this changed since?
- There may well be people wanting to use GUIs. "There are GUIs for Arch, but they are still young." (Same website)
- Do we really need decentralized development since we will only want to have one server running for now?
Ansgar?: I think decentralisized development is nice for private branches and developers other than the core team. Also it's nice to be able to do commits and checkout offline. I haven't used Arch on Windows or tried the GUIs yet so I can't comment on that. But I don't insist on using Arch, CVS is also fine by me. But I think Subversion maybe isn't the right choice, mainly because it's not supported by SF.
Ansgar?: I suggest we create a mailing list (ultimatego-devel) on SF to discuss things. I think it's much easier to follow a discussion on a mailing list than on a wiki.
Needs domain name, web space, bandwidth. Compare with web sites of KGS, IGS etc.
Ben: From the discussion below and some private talks with experienced people, I've drawn the conclusion that probably Java will be the best. The biggest reason is the client being written in Java as well, which means for us that:
Also, I think that right now Java is much more popular, e.g. it is taught at the universities, so the more developers can join us with this.
About J2EE etc.: Yes, these platforms offer some good solutions to problems we will have, and for someone very experienced with it it would be a good choice. But this is not the case when looking at our resources - in fact just gfeng seems familiar with it J2EE for me. As this environment seems rather difficult to learn working with, we can't use it for this project.
So I hope everybody can live with Java as language for both server and client. Maybe then we can stop this discussion and instead use our energy in a more constructive way instead. We should really define now what features we would like to have and try to get a complete vision of the server before starting to implement the first version.
Fwiffo: I understand the importance of making an executive decision here, but I want to be sure the choice is made for the right reasons. I don't necessarily even disagree that strongly with the choice; I hate Java with a firey passion, but that would only be enough to relegate it to second choice on my list (my hate towards other languages is generally more firey). Since we don't really even know what the server is going to be like, maybe this is a decision that could be put off (perhaps a prototype could be produced first).
As I mentioned below, there is no reason the client can't be written in Python too. There are good cross-platform GUI toolkits, Python code is very easy to write in a portable way and virtually all good Python libraries are completely portable. It is possible (in fact, easy) to produce standalone executables for Windows so you don't even have to have an interpreter/VM installed. So, all the advantages you list for having the client and server being in the same language applies just as much to Python as it does Java.
Python seems to get a short shrift from people who don't really know it that well, which I think is a shame. It really offers some things I think would be great for a project like this - microthreads with stackless Python, Medusa or Twisted for a networking framework, etc. I do not feel that unfamiliarity with the language is a barrier to programming in Python - there is no language easier to learn.
maruseru: Earlier, you said "I'm going to recommend against Perl and for Python". So, one could say that Perl too seems to get a short shrift from people who don't really know it that well. Sorry, but I've done quite large projects with it and it's fully capable of this kind of work. As is Python, as is Java. Again, stop the language wars. Especially now that Benjamin has made a decision. The reasons he gives for his decisions are all valid and thus I support it. We could argue about this until the cows come home, but let's not. Let's rather move forward.
Fwiffo: I had years of experience with Perl before I ever learned Python and have used it in projects large and small. I still use it almost every day. Perl is my second favorite langauge and I get pissy when people denegrate it unfairly. My reasons for objecting to it for this particular project are based on my extensive experience with the language, not some hysterics about whitespace or some junk. There should discussion that should be about the real capabilities and deficiencies of the languages for this project, not about ideology or a language holy war. I don't think that discussion has taken place, but I don't know that it needs to take place yet. There is so much that is still up in the air, and I don't really think that a firm committment to a particular language (when we are still so far from needing to jump into code) is necessary right now, especially if that decision is based on incomplete or inaccurate information.
That's the last I'm gonna talk about language for now - I agree that the discussion should move on to other things at this time. I also recognize that I'm a total hypocrite because I'm the one that's been dragging this out.
Benjamin: Well, of course, during server structure design we could encouter structures that would be easier to realize in python than in java or vice versa. So, Fwiffo, if sometime later we really get to the conclusion that python would be the clearly better choice, we can start thinking again - that's for sure, as noone is interested in using the worse choice. Although I don't think this scenario will happen... I just consider above as "decision for now" in order to stop this debate and instead start with the concrete design. If (and only if) we really encouter some ugs-specific stuff (and not just personal ideology) that make a choice apart from java preferable, we can start talking again. But for quite sure, everyone should plan with java...
Fwiffo: That sounds fine - I'm more than satisfied to move on. :-)
Although it's still a very early stage, we can already have some thoughts about the implementation:
maruseru: I strongly suggest UGS be open source. That way you can have all the benefits of open source development (high security, quick turn-around of bug fixes etc.) while maintaining control (only a core team can commit patches). Possibly use sourceforge as the infrastructure.
There would also need to be a UGS client, which should be based on an open protocol, so that everyone who wants can write their own client, and so it's easy to write a GTP adapter (to run go-playing programs on UGS).
Have you thought about the development languages? For the client, it'd be ideal if it was portable with minimum effort - which points to Java (otherwise not my favourite language). For the server, you'd be free to choose whatever suits you best. I'm totally into Perl, as it gives you the greatest combination of freedom, flexibility, portability and reliability. Plus its community and vast library (CPAN) are its main assets.
nachtrabe: As to Open Source, I'm going to advocate the BSD license. I'm not Anti-GPL, but I prefer to work under BSD-style licenses when given an option.
maruseru: To get into the boring details of all those licenses, see
http://www.opensource.org/licenses/ . I'd like to see the Artistic License used, which has worked very well for Perl itself and for other software projects, as it gives you more freedom than the GPL. When I created the sourceforge project (which has yet to be approved), I had to select a license and some implementation details, and for now (I hope that's something we can change if necessary) I've gone with the Artistic License and Perl. We'll see.
A client may be important to develop (I'm not sure I agree that one is necessarily needed--maybe a command line client?), but I think it would be best to focus on the server side of things and try and advocate the adoption of the protocol to client developers.
maruseru: We should have at least a default client with which to test things out, so it's a natural requirement.
maruseru: I believe the protocol is one of the most important things - once you know what it's supposed to be able to do, it's much easier to design a server and a client for it.
maruseru: Another idea would be to integrate the UGS server (and/or the client) with the GoRepositoryProtocol - something I've thought about for some time, but never bothered to write about. Now that you've started the UGS brainstorming, it seemed like a good time to create a page for that as well.
Benjamin: Yes, some protocol like your GRP has to be invented to store/use anything in a comfortable way. Also, we will probably need new game/analysis/problem formats different than SGF, but that can be discussed later.
Pajaro: I've been thinking about this idea. You say open source, open protocol, multiplatform... I was thinking: would it be possible to use Jabber for this? There is always an open protocol to exchange information, and open clients too. It is multiplatform. You could think of a room in KGS as a stand-alone server. If people wants to join a room, you just log in a certain server. Of course you must have a way to know about all other servers but I guess this could be worked out. What you also get is that you don't need a big server for everybody. Anyone can run its server, and can communicate with each other (or not, as you wish). In the coding side, you aren't tied to a specific language either, as long as you use the same protocol. In other words, you would "only" need to make a new component. Would this be possible?
Benjamin: Interesting idea. When the time has comen to choose language, we should think of this in more details
nachtrabe: One idea would be to use either XML or S-Expressions. My desires for a protocol is that it should be:
As to communications protocol and language, I'd like to advocate using Python with Twisted (as I state in my intro).
Just my 2¢
nachtrabe: So far I've heard Perl, Python, C/C++, and Java. These are all options and each has their own strengths and weaknesses that bear consideration. What are people's thoughts on the matter?
Benjamin: I love C# btw.
gfeng: With c# you depend on Microsoft - is this really what you want?
Benjamin: Aren't there free C#-compilers for linux etc. as well?
gfeng: Yes, but far from complete. You know Microsoft, they change with the next version elementary API and the work has to begin from beginning and I believe, that MS will not giving .NET out of there hands to an open community. And mono is (at this very moment) only available at MS Windows, some Linuxes and MacOS-X 10.3 - no other (Solaris HP-UX, and so on). This is maybe not importent to all, but in my oppinion it is a restriction.
maruseru: My thoughts are Perl for the server, Java for the client. At least with the choice of Perl, I'd be able to help with the project.
nachtrabe: With Perl, I wouldn't be able to help. Whatever language is chosen--unless it is C/C++--some people are going to be taken out of the pool of potential aid in the actual coding (design is another matter). The best option here is to create a listing of the pros and cons of each of our major options (C/C++, Python, Perl, Java, and we should probably throw Ruby in there as well). As to the client, creating Yet Another Graphical Client from the ground up sounds to me like reinventing the wheel and something that will distract from the server more than help it along. I would like to suggest making a basic shell part of the server that someone can telnet in and see the full output. When the protocol reaches a certain level of maturity the next step would be to take another open source client that currently is used for IGS and NNGS and fork it, adapting it to fit the UGS protocol
maruseru: Not to denigrate any language or something, I'd suggest using a dynamic language such as Perl or Python. Java may be necessary for the client, but for the server it's madness, as is any compiled language - it just doesn't give you the same flexibility in testing out new things. You always have to make a build, which is an extra step that tends to get on your nerves pretty quickly. And compiled languages such as C++, Java and so on aren't as flexible, usually insisting on strict typechecking and such. Please, please, don't use such a language for the server. It's not just speed of execution that counts, but speed of development. And well-written Perl/Python code can be just as performant (except for time-critical things) as a compiled language. I'm not getting into a language war here, just strongly stating my opinion :)
I can't believe you're touting perl for ease of use for something as complex as a server. Java is right out as it will keel over and die with appalling regularity, I think most people choose C or C++.
maruseru: I can only speak from experience :) Perl is useful precisely because its flexible and easy to use, and it has a huge library of useful modules (CPAN). And there are plenty of examples - just look at what mod_perl can do. But for a much more eloquent explanation than I could ever give, please read Paul Graham's essay
Beating the averages.
nachtrabe: Oh, no disagreements here! I far and agree with your assessments about static languages for this kind of thing, I'm just throwing C/C++ and Java in because if I don't someone else is going to start yelling about how they weren't even considered ^.^ No, getting out the abstract realm of treating everything equally and into my own personal judgments on the matter, I definitely think that it C/C++ and Java are both just the Wrong Tool for the Job (WTftJ). As to Perl... whenever I think of it I think of that Jedi joke where Luke asks Yoda "but how will I know that Python is better than Perl" and Yoda replies "when in six months try to read your code you do, know you will." ;) My experience with it has been very minimal (some CGI, that's about it), and so I'm going to defer on judging between that and Python for this kind of thing until I've seen more about the relative pros and cons for a server of this nature.
maruseru Perl and Python are largely the same when it comes to basic principles. They're both dynamic languages with good ideas behind them. They differ in how they look, but just because Perl makes possible some weird constructs doesn't mean you have to use them. It's quite possible to write beautiful Perl applications, and it's quite possible to write ugly Java code. Just because it says "class" at the beginning doesn't make it object-oriented. It depends more on the object design and stuff like that. Just because Perl has sigils ('$', '@', '%' etc.) doesn't make it unreadable. Python is quite clean as well, and has its merits; it's just that Perl is my personal preference. Of course, it all depends on who is going to be doing the development - people should feel comfortable with the project.
gfeng: For a project this big, I think scripting languages such perl, python, ruby and so on are not powerful enough. In my oppinion, this is a classic task for some kind of enterprise technologies. Only for example: thinking of scalability, fail safety and so on. This is in scripting languages an horrible and nearly impossible task. Take J2EE, this is better for such projects.
maruseru: gfeng, do you have a lot of experience in dynamic languages? The things you describe are absolutely possible in those languages, given the right environment - for example, Apache 2 plus mod_perl 2. I don't know very much about J2EE, but see that it's overly complicated. You may not know very much about Perl and believe that it's not powerful enough. In reality, both will probably be able to do the job, each in its own way. But with J2EE, I'm out of the project (not that it matters, just to clarify).
Benjamin: Oh shit, now we've got two projects... Sorry gfeng, as you didn't answer my mail, we already registert "ultimatego" as SF-project. Maybe you should remove the other one then...gomen
Rakshasa: How is Apache 2 + mod_perl the right environment? Large websites handle small number of relatively large requests content as fast as possible. A go server would need to keep thousands of persistant connections and frequently send small amounts of data. You need a different way of polling sockets than what web servers provide.
maruseru: Apache 2 is basically a framework that supports all kinds of protocols. And even before, long sessions are possible with session cookies. Just think about all those internet applications; they last more than for one click.
Rakshasa: Yes it does support alot of protocols. (Not all, but very many) But it does not support all kinds of server designs. Apache is design to use alot of threads that each handle a few connections each, not what a go server should use. I know about web applications and session cookies, this isn't the right tool for this job imo.
nachtrabe: I am going to strongly disagree. Dynamic languages such as Perl and Python are more than powerful enough and ideally suited to projects with exactly these requirements--including the size. Python, for example, has a proven track record with large projects, and I know of at least one MUD that was built with Perl.
Benjamin: I'm not so well informed about Perl, Python, J2EE, so I've talked with a few people about it. I've got the general impression that Perl might be difficult for the team to use properly, as it tends to produce unreadable code. Java might work out better in an open team. J2EE seems a bit like overkill. Pure Java might be a possibility to find a consense.
Rakshasa: I guess it's time for a joke: The Gnome spoke up, "Don't parrots usually have, I dunno, beaks?" Perl looked stricken. "Well, he's not finished yet. I'm a little behind schedule, if you really must know." "Yeah, yeah. So, what's he do so far?" Perl brightened up. "He can turn into a snake! He's more snake-like than a real snake, for four out of seven criteria acknowledged by the American Herpetologists Association!"
Fwiffo: I'm going to recommend against Perl and for Python. I'm actually a pretty big Perl booster and someone who uses both Perl and Python virtually every day, but for large, object-oriented projects, Perl is masochistic. It's object semantics are exceptionally unhelpful. Python, on the other hand, is much more maintainable, readable, etc. Frankly, if I was to work on a large project like this, and I had my druthers, there is no language I would choose over Python. Dismissing it as a "scripting language" is unfair. I know a lot of people (and I used to be one of them) who balk at its indentation oriented syntax, but I suggest you get past that and give it a try. Staying away from Python because you fear its whitespace is like avoiding perl because you don't like dollar signs or avoiding Java because of the insipid coffee jokes. Python is a very easy language to learn; you can get into it in about 20 minutes.
I have a very low opinion of Java and related technologies. Its primary positive feature seems to be excellent marketing. However, it is "the standard" these days, and there's lots of work out there in that area so it should be considered, and I think it's preferable to C/C++.
I have less experience with Ruby, but from what I like what I've seen. The drawback would be the less extensive reservoir of code compared to e.g. Python. OO purists may prefer it over Python.
So, in my opinion it comes down to whether you want a dynamic language (Python, Ruby) or static (Java). My vote would be absolutely for dynamic languages.
nachtrabe: Here are the reasons I think Python is the Right Choice™ for this project. It should be noted that some of these apply to other languages that are being considered (such as Perl) and I'm leaving out a few items (such as scalability) without which it would be completely unsuitable. They are roughly in order.
Skyr: You can't be serious about your Python arguments. Sorry, it is nothing more than a (probably one of the more able) scripting language, just like Perl. "Rapid development" is an advantage of most scripting languages, yet their approach tends to make larger projects hard to maintain. "Readable code" can be produced in any language. And on the point "It doesn't assume the programmer is stupid"... I'm feeling like I'm played for a sucker when a programming language forces the way code is indented (beside the mess tabs vs. 2 spaces vs. 3 spaces vs...) - this is one of the most ridiculous concepts I've seen for a long time. Sorry about that. (axd: I agree) But what is better? I suppose Perl isn't :-) The same "scripting language" arguments go for PHP... I'm one of the maintainers of a large PHP project; PHP was definitely nice for coding, but there seem to be hard limits in performance when it comes to heavy database access. One of our web servers is running with an Apache/Tomcat/Cocoon backend. It runs quite nicely - except for some file descriptor leaks in Cocoon. So if you leave out Cocoon (which we wouldn't need), it might be a stable base for the project. I've been programming a lot of Java in the last five years (at least), which gave me some sort of a love-hate relationship to Java :-) Java has many drawbacks (huge memory demands, sometimes performance deficiencies), but yet it often was the easiest / most fitting solution for many problems. The possibility to use the same framework for both backend/servlet programming and in a script-like way (JSP) seems quite impressive to me. The last alternative would be the use of C/C++ - which would definitely the hard way...
axd: When reading all this, it looks like a language war is coming up.
nachtrabe:
Don't take my
word for it (PDF). It has also been used to implement
Voice over IP,
Kombilo,
XCircuit, as part of
Google, and
Eve-Online. Quite something for "just another scripting language."
I should also mention that Python has a good track record of being easy to maintain and expand upon even in large projects.
Commenting to axd: "Rapid development" does not--in any context--mean "sloppy development." Even with inexperienced programmers. The concept of "rapid prototyping" is a term out of software engineering that is unrelated to "hasty coding" or the "big bang model of software development."
Rakshasa: Might i point out that none (as far as i can see) of the above examples use python for a server of this kind. The closest you get is the mmo game that uses stackless python as a rules scripting language.
Fwiffo: Depends on how narrowly you define "server of this kind".
Rakshasa: 5000 and more persistant connections, that's how i define a server of this kind. Any events would need to be propagated to a random set of peers. This requires imo multiple threads to handle a few houndred connections each, and they would need work on the same data set.
Fwiffo: The arguments I always hear against Python come from people who don't use Python. The whitespace argument is completely bogus. I know that for a fact because that was always my excuse for not learning Python. The argument about scaleability/maintainability also shows a lack of familiarity with the language and its success in large projects. In any event, nothing will be solved by perpetual language holy wars. I could spend weeks dismissing static languages as malignant dinosaurs, and the Java fans could continue to dismiss dynamic languages as toys or "scripting languages" for parsing log files.
maruseru: So, the only thing we seem to agree on is "I don't know what the hell I'm talking about, but I'll strongly say that Perl/Python/Java (delete as applicable) is shit and Perl/Python/Java (delete as applicable) rules". Well, thanks - I was wondering about the merits of discussing this in this forum, but now I'm sure that something like this shouldn't be a community decision. Someone should (and probably will) just start it, and the rest will join the development, or they won't. Good luck with it all; this bickering is pointless.
axd: whatever language used, before jumping to code, one should have a good idea of what the end product will be required to do, and put time in this stage: maybe when this is clear, then only might a discussion start on what language (or combination of -) is the best; what components are already available out there, that could be re-used. Iterative development is one thing, but starting to code too soon can't be good. I think that at this stage, the choice of language is not relevant: this stage requires thinking of features, voting maybe, thinking again, and thinking again, structuring requests, giving an overview, comparing features of different servers, realise that maybe we are biting more than we can chew. I don't think time is money here; time pressure is a big source of problems afterwards. And you can't expect such a project to take off after having published a few pages on SL? Again, patience just pays off. There will be many more suggestions that will pop up, as more people will discover the page.
dnerra: I am not sure I will have time to help with the programming, so let me speek as a user. As a user I don't care which language is used on the server; but the choice for the client obviously affects me. Please choose something that will end up being easy to install for the end user. Java has the obvious advantage that simple users won't have to install anything, and can just play with their browser; and a proper install is not so difficult either. As for the other languages, it depends on the GUI toolkit chosen. If there is just one additional library install, you will lose many users on this step who just wanted to try out how this new server looks like. From the programmer's viewpoint, I personally would prefer a strongly typed language for any project with many contributors; but I agree that this is an issue that can be overcome with good discipline on commenting and coding style.
Fwiffo: It's sorta been assumed that Java was the only choice for the client, but Python with wxPython (a cross-platform GUI toolkit) is also a possibility. The major platforms (Windows, Linux, Mac) would all be supported, and code could be reused from the server project. Producing windows binaries of Python programs is easy (the end-user won't have to install an interpreter or libraries or anything).
maruseru: What are the skills of the development team (regarding language experience, databases, xml, network applications, website design etc.)? I don't say we should go with those skills just because they're there, but it'd be good to be aware of realistic options, at least.
Hikaru79: Oh, wow. I can't believe I never noticed this page until now. I *really* would like to get involved. I know Java and Ruby (and I suspect my Ruby knowledge can carry over to Perl/Python), and I'm only in high school so I've got all the time in the world to dedicate to this excellent project! Since it seems this has gone semi-official, can someone *please* let me know what e-mails to send, who to contact, in order to get officially involved in this? Thank you :)
Benjamin: Well, the page just exists for a couple of days yet - that's why you didn't find it^^. The most "official" members right now are in the "iterested" list at the main page. Just add yourself there...
juhtolv: Don't you realise these goals are mostly in contradiction:
Go-software written in Java. Oh, no! Not again! Very soon you'll end up using Java-implementation by Sun and it is not open source (or free software) and therefore your software is not really open source. There exist those really free implementations of Java, for example GNU Classpath, SableVM and Kaffe, but I fear they are not good enough for your project. And please read these:
Perl and Python are interpreted languages and therefore they may be too slow for this kind of project. But for client part they may work fine. Bigger project like this tend to need object oriented programming, so C is not suitable. So, I propose you use C++ at least in that server.
geno: Once I wanted to compare the speeds of C, Perl 5, and Parrot (the byte-compiled back-end to Perl 6; it looks like assembly code). I wrote the same program -- a program to calculate the julian day number, including both integer and real arithmetic -- in all three languages. C was 7-8 times faster than Parrot which was 7-8 times faster than Perl 5. C was about 50 times faster than Perl 5.
Please consider this just an FYI. Speed alone isn't the primary factor; I suspect server ability to move packets and code quality will be way more important; these issues definitely need to be addressed by people with more client-server coding experience than I have.