Ok guys, we have several developers interested and a lot of great suggestions already. We're also hopefully going to have a forum available soon so discussion can be easier than this blog allows.
Before we can "dive in", a few choices need to be made. Obviously we must have some sort of storage backend, some server side code, and some client side code. A natural choice for managing all this is one of the MVCish frameworks out there, but which one depends mostly on the language of choice.
So far PHP and Java have been suggested. I personally would lean towards Java given the complexity and security needs of this project, but I'm sure PHP could also be made to work. Luckily most of you who have responded have indicated a wide range of skills and a willingness to work outside of your personal favorite systems, so I think we have the opportunity to chose based on the most suitable framework without upsetting anyone.
Priorities for a framework would be scalability and strong AJAX support. No need to make things hard on ourselves :) Of course that still leaves many options. If everyone could think about the options out there and which they would suggest, we'll make this topic #1 when a forum becomes available.
Subscribe to:
Post Comments (Atom)
What would be a interesting idea is 2 projects, one PHP and one Java. Its basically the same, just with different ways to do certain tasks, Java displays different to PHP, but they could both do the same task of displaying information.
ReplyDeleteno way java. java was supposed to burn in hell long time ago, but somehow it still is alive. do not make it in java, for Christ sake, please, I beg you devs, I beg you so much!
ReplyDeletebesides, if i`d ever want to host virtual monopoly table for my mates, i`d kill myself while putting correct java on server and configuring servlets correctly.
Please, no Java. Please.
about maps. OSM maps are great, but I guess you still have to cache street vector data. why?- because someone could delete road (and maybe redraw) and in-game street owner would loose it`s property.
ReplyDeleteRegarding the OSM map data, another good reason to cache it is for bandwidth / performance reasons... that data will most likely be used a lot, so would save bandwidth if it was cached locally to the server (and I can't imagine OSM would be happy about the potentially large number of requests!)
ReplyDelete@Jancis the Java hater :)
ReplyDeleteI am open to all suggestions, but you're being a bit harsh to Java. Its not my language of choice, but its by no means dead. In fact, it is the most popluar language in use today by a good margin, twice as popular as PHP (see tiobe popularity index for sept 09).
There are also some very good MVC frameworks for Java and nice persistence libraries. Yes, it can be a PITA to code, but sometimes thats because it enforces a certain amount of sanity. As for setting up a server, theres not much simpler than installing Tomcat and dropping a .jar in the directory.
But like I said, I am open to whatever the consensus is, and I'd really like to avoid any religous wars or have language choice become an impedement to progress. We could always come up with an API spec and let people write in anything they want so long as they implement the calls.
What are some good frameworks for PHP that support AJAX and persistance? I will be doing some research myself but any suggestions are welcome :)
regarding OSM data, I believe MCS is using their own copy, I seem to remember mention that their copy is out of date. I suspect we would want to do something similar, since as was mentioned we need a static street database or we will be open to strange abuses. We also probably need to augment the street data from OSM with some precalculated info for efficiency (cost, possible cache intersections if we use these in some way) and of course we'll want to have this data in a fast database with our own indexes. No way we could do lookups to OSM on demand.
ReplyDeleteOne last thought.. anyone used Ruby on Rails? Seems to have some nice features, and supports a variety of DB back ends.
ReplyDeleteI'm a fan of CodeIgniter on PHP personally. Add another PHP vote.
ReplyDeletePHP is very much capable of handling it all.
Its a lot of data and PHP manages splendidly.
I have experience working with OSM dumps by the way.
I use parts of them for my day job, along with other data sources.
We will need to use our own copy of the OSM database which is straight forward, but we will need a 'merging' feature so we can apply diffs to keep it up to date.
I do have quite a bit of resources server wise which I'd be willing to use for a project like this. :)
I also go for PHP... Yeah, it has security breaches but if we keep our eye on it i don't think it'll be much trouble to us.
ReplyDeleteHere is a link about which famous websites use PHP/MySQL
http://www.davidhurst.co.uk/2009/02/25/famous-websites-that-use-php-andor-mysql/
Current MCS game uses PHP but its defficiency is not because of PHP but because how it is coded.
But truly, I wouldn't mind if we chose Java for it. This is a big project both PHP and JAVA could be used for different purposes.
Choice of language depends on real, specific, project needs and not language features or programmer experience or preference.
ReplyDelete1. Usage is not a factor.
JAVA is widely used for a broad range of
apps including web apps.
JAVA has visual frameworks to develop such apps.
PHP is widely used for web apps and delivering of content.
PHP is more code oriented and frameworks are of the CMS/CMF style.
2. There's no such thing as a ready to run framework.
There's wide support for AJAX, SOAP, XMLRPC, etc.
PHP may be better for opensource and JAVA for client apps.
3. Security is handled by the devs, language only provide tools.
PHP from scratch is exposed to injection, yet this is a coding task.
Measures can be taken to secure both the code and the server.
Bugs are also tied to performance, as web apps are often not optimized because content delivery should be simple.
4. Performance.
PHP works together primarily with MYSQL, APACHE, and secondarily with other server tools like the php accelerator, squid proxies, memcache, etc. and these are only optional for static pages.
Dynamic apps tend to rely on the template or database while keep code must be kept on files as possible and data in any forms of page cache.
In JAVA the compiled code fulfill most of this need yet the principles are the same.
Lack of caching and bloated code can indeed affect a JAVA app.
5. Server AND coders availability.
Tomcat is an added setup to LAMP servers.
Linux boxes are cheaper and accesible to opensource colaborators, over windows.
These may be still true for desktop setups.
6. Updates of an opensource project are not trivial.
Maintaining the code is not an easy task, the more people involved doesn't hinder the tasks
An opensource framework usually have a long or yearly lifecycle.
The new version goes through coding phase early in the year, testing around summer when more people can help troubleshooting, afterwards ending with addon modules.
7. Duplicating efforts.
Existing technology should be used where possible.
In JAVA the app depend on the needed libraries.
In PHP the app can integrate with a content manager and its modules.
Browser compatibility applies, as with javascript and flash.
This keeps the core of the app simple, embeddable and portable.
8. Limitations.
File formats may introduce limitations such as KML having to expose data to the client.
Java may be preferred over flash due to licensing yet client code can be left out of the scope of the project.
An API is the ideal form to allow the development of clients and modules and focus on the core code.
Authentication issues can also be strenghtened with extra steps like captchas, throttle, ip logs and session workflow.
9. Database size.
OSM database may have fixed size yet outputs large data in a slow and intensive queue.
This may benefit from caching tech.
The data may need to be exposed to the client for performance, allowing scripting may be actually desirable to some extent.
It is the interaction that needs be secure.
Steps should be taken to avoid overwhelming the servers and delay bots.
E.g. what is done in forums to limit text searches per user.
10. Move the important blog comments and suggested guidelines to a summary thread on the forum.
Else people is doomed to make dupe comments over and over.
Readers can also take note of useful things like coding standars, formats, project managing and issue tracking, roadmap, versioning, compatibility, portability, etc.
Remember that most testers are end users requiring usability.
Devs can't be bothered with usability but focus on API and review patches.
...curse the 4096 char limit XD
I'd forget about java/php.
ReplyDeleteDo a simple frontend in Ruby/Rails that only deal with mundane tasks such as user registration and so on. Simple and fast to do.
As for the ajax on the server site, do it with Erlang spitting out json. Hell, even make a XMPP interface for near-to-real-time-push updates.
Use a columm oriented database such as HBase/hadoop as for maps/tasks/updates and PostgreSQL for general user info, stats generation, blabla...
My 2c.
Ruby on Rails is no way near popular enough or widely used to consider using it as a main distribution.
ReplyDeleteWhat i can see happening is multiple code bases (java, php, .net, ruby on rails etc) integrating with a single back-end API.
I think the aim has to be for a central version running.
An API structure would allow for different servers and applications to work with a single OCS version e.g a java based front end on server A located in london, php on server B in the USA, .net user on server C etc. This would also distrubute the hosting load and act as a resilient cluster.
Needless to say though, there would need to be some serious database kit running behind the scenes if the system got anywhere as popular as MCS.
So the question is, what should the backend be written in?
I'd say PHP =)