Ok, restarting from square one.
Actually, I reread what I wrote. The most important stuff is after the ****.
Ok, let's think about what the advantages of some langauges are over others, and the feature one would need in an FE.
So, I am going to ask a bunch of questions.
Very first question. should there jsut be an open source backend? Since everyone has their own opinion on FEs it is impossible to make an open source FE everyone will like. But I'm not stopping you:)
Second, should it be crossplatform?
Actually, I have mixed feeling on this. It definately won't be for macmame has that is like mame32, it has it's own gui.
But for OS X, linux, any other unix port it would be nice.
Second, this answer somewhat depends on if it should be cross platform and just a backend. Should the data be stored in text files or a db. Personally, if it isn't going to be crossplatform then a DB is great. SQL is very fast and really easy to use to get the data you need, no multiple parsings of text files, smaller memory footprint. Yes, a small memory footprint is somewhat important. Not everyone is going to be using a 2Ghz machine is 1g of memory. Some of us have a PIII650 with 128 megs of ram in their cabinet. well, if oyu want to play a larger rom you need the memory open.
However, text file does have it's advavtages. A pure textfile has a huge disadvantage of that you need to manually parse. However, that's where XML comes in. Using an XML parser does all that for you if you store the data in XML format. Also is a textfile is crossplatform too.
If one uses a text file what language is best suited for it.
Non cross platform, VB.
Cross platform, java. Java has AWESOME string parsing and an very good XML parser, so I hear.
c++ sucks at string parsing. Though, if it wasn't cross platform, only on windows, it is really easy to use XML 4.0 from M$.
Now, one would say why not include c++ if it is crossplatform. Well, c++ code may or maynot be crossplatform, the executable isn't. With java, the whole purpose of java, is to have to make the bytecode only once and be able to run on any machine.
So, after all that is said, for a backend I suggest this:
not crossplatform: VB with XML or Access
crossplatform: java with XML
now, this is just the backend. That means an FE would have to talk to it. So being able to easily interface with it it important.
Non crossplatform: VB solution, use a dll. you can;t get much easie to interface than an axtiveX dll.
crossplatform: well, there's java's downfall in this situation. It would be very hard to make a non java FE then.
Ahhh, but there is another solution to the crossplatform then. One, you'd have to use a flatfile textfile, not XML. Second, it would be done in c++ code. The code itself would not compile into anything, liek a dll or exe. The c++ code is just classes to access mame and the data. You then just have to add those classes into your c++ FE project.
****
There are many different solution to this problem. Guess what, there is an FE for almost each of those solutions already.
That makes you think, WHY make a universal backend. easy, configuration. We all know no one can agree what the best FE is. That's why there are so many. Each person has their own taste on what an FE should be. BUT with a universal background, each FE would pretty much be configurable the same way. It'd make switching FEs easy or trying out someone elses much easier. now, my question is, do we really need that?
Actually, what I think is more needed, is something like my c++ solution idea above, but for each language. That way an FE developer just has to add files to a project and not worry about anything but GUI and usability.