Software Support > controls.dat

Would anyone like to take over?

(1/9) > >>

SirPoonga:
Other priorities in life are above this project.  I would love to continue to work on it however I think I need to pass the torch to keep it going.  I will still help out when I can.

So here's the deal.  I think the project's site needs a complete overhaul and brought up to date on technology.  It is currently written in old php which is probably not secure.  The database design is horrible.  I started this project 10 years ago when I just got out of college.  Now when I look at it I see my inexperience.

So I would suggest if someone wants to take it over to start designing a website for it.  Currently all the data is in a MySQL database.  I can help convert the data to a different schema or format.  I could see a complete overhaul of the output file to xml and json with an iphone and android app that works with your cabinet.

Howard_Casto:
I've been wondering where you wandered off to.

I was thinking about the project today and I thought that maybe a different approach is in order.  We tried to do it all on the web and in a perfect world, that is the best method.  The problem was it never worked out that way.  Anytime mame did a major output change (which was, and still is a farily common occurance) you ended up having to muck about in the database and manually change stuff.  Users had to wait anytime you modified anything and after you did get the db in line you usually had to modify the xml output and the webpage's wizard interface.  It was doable, but a time-consuming process, and everything had to be put on hold anytime major changes were made. 

On the other hand headkaze and a few others made offline apps.  I don't necessarily think this is the way to go either.  Offline apps lack a centralized database and version incompatabilites as well as lack of user proof, could cause a problem. 

I do think that a hybrid of the two methods might work.

The centralized database, the official version of the dat, and all the output reports would still remain on the site.  Instead of a wizard system there would be an offline app you download.  The app would require a web-connection anyway, and make submissions very similar to how we used to do it.  The only difference is, when something changes all of the wizard stuff as well as control types, ect would be on the offline app, so it would be much quicker to fix.  The only thing the site would recieve would be a pre-formatted DB entry, which could be read via the admin's offline app and approved, just like the old system. 

If the server-side was setup properly, the site should be much more secure.  Normal users would only have read acess to all sections except the submissions ftp, which could be completely cut-off from the rest of the site.

Generation of the xml would also be easier.  That could be done via the admin's app and uploaded via ftp, so a server side solution to generating those files would no longer be needed.  The site could just access the unmolested db directly for reports, which hopefully would make things easier.

But I'm just throwing ideas at the wall here.  I'll still be an admin, I can offer to redesign the xml format and handle mame input changes, and if an offline app is needed I can write it and maintain it.  Online databases are NOT my thing though, and I wouldn't be comfortable doing the server end. 

drventure:
I'd love to throw in, but I'm a bit swamped with my own things right now too.

One possible solution I'd throw out.

Would it be feasible/dump/insane to do something like...
1) base the INI on the XML(or vice versa) and generate one from the other
2) then, put the INI or XML file into a public version control system like CodePlex or Github.

Then, different versions could be easily tracked via the normal versioning systems inherit to VCS's and any updates/user mods could be vectored through any of several moderators via pull requests (ie uploads of changes made by a user that aren't integrated into that version until a mod decides it's ok).

Granted, contributing might be a little more difficult (maybe too difficult?) but it might help take some of the burden off the moderators.

Howard_Casto:

--- Quote from: drventure on August 31, 2012, 11:22:03 am ---I'd love to throw in, but I'm a bit swamped with my own things right now too.

One possible solution I'd throw out.

Would it be feasible/dump/insane to do something like...
1) base the INI on the XML(or vice versa) and generate one from the other
2) then, put the INI or XML file into a public version control system like CodePlex or Github.

Then, different versions could be easily tracked via the normal versioning systems inherit to VCS's and any updates/user mods could be vectored through any of several moderators via pull requests (ie uploads of changes made by a user that aren't integrated into that version until a mod decides it's ok).

Granted, contributing might be a little more difficult (maybe too difficult?) but it might help take some of the burden off the moderators.

--- End quote ---

I personally never liked the xml version just because xml is less readable to human eyes.  That being said I eventually dumped support for the ini because it turns out that the windows api calls to read/write inis have a 64kb limit.  Now for any sensible db this wouldn't be much of an issue, but mame has an insaine amount of games and thus I hit that limit pretty fast.  Seeing as how a person then had to parse the file manually, sans any helper functions, it made much less sense to use the format.

The plan as of the next upgrade to the format was to cut the cord and remove the ini completely. 

Now xml parsers obviously don't have this problem, but xml files, due to their massive amount of waste (too many flags and white space) up the file size dramatically.  I don't know if you've noticed, but the current listxml produced by mame is just shy of 100 megs! Now obviously controls dat is much smaller, there is less data to contend with, but we've got to assume that as more entries are added, the total file size will become a concern. This isn't really a big deal on modern computers, but it is a killer for any site that hosts the file. 

So I think a regular database is best for the online component simply to reduce the file size. 


I think VCS  is a little daunting for a guy who just bought a dataeast control panel and wants to make a single dat entry.  I could be wrong on that though.

A code repository in general isn't a bad idea though.  The only problem is how to make it user friendly.  Pretty much nobody aside from SirP and myself can write a complex entry manually because nobody but SirP and myself fully understands the craziness of the format.  We would still need some sort of wizard, either offline or online. 

Another major hurdle of the project was mame's constant renaming of roms.  Entries had to periodically be compared/parsed through a diff file to make sure none of the rom names changed.  Now 99% of your controls.dat entries are parents, so it rarely effected much, but when it did, it was a headache (for sirp mostly).

I think now would be the best opportunity to completely ovehaul the db and the format.  So ideas... they need to be posted.

SirPoonga:
beenbusy

Navigation

[0] Message Index

[#] Next page

Go to full version