RomRaider

If you refuse to take your blinders off, so be it. but please go through this list form the OP and explain point by point where you disagree.



I still don't see any merit to a database, especially a private database with private tools. It's best attribute is that it can manage multiple definition sets. Multiple definition sets is a paradigm that should be worked to eliminate, not entrench. Same goes for the centralized/private stuff. Sure, there needs to be some gatekeeper be it a process or a person, absolutely.. but it needs to be at the end of the development workflow (vetting for stable/beta release), not halfway through the process, and certainly not in the shadows.

Unless I am missing some other unique relationship, all of the necessary data and relationships can exist inside a single xml set.



Please clarify this.

What dschultz is trying to express is that the average end user just wants to download a definition file set, plug it in then start tuning.... some don't even know what xml is. For the more technically versed users, I think your Git depository is an excellent idea that saves endless hours of going through posts as I know you have

And for the end user, we have this:



That is, they don't even have to bother downloading unless they need something new. They don't even have to know what a definition is!

We can go a step further and have an 'update definition' button to fetch the latest set, then you don't even have to open a browser, much less dig through a forum, xml snips, etc..

I was going to ask about auto update capability... I'm in!

That would be a big plus...

As requested my comments are in bold.
Better tracking of definition history/changes. - agree you can see the changes
Easier to implement standardization of new tables, scalings, descriptions, formats, etc. - nope, that has to be defined before submission to the repo
Ease of use for end users, no more scouring a forum to find definitions or get an updated def. - they need to scour the Git repo instead
Easier to collaborate and stay organized. - probably
By pointing RomRaider or ECUFlash at the local repo, you can easily switch between different branches for quick tests/comparisons. - this functionality does not exist in either application at the moment, but I like the idea
-this will allow the RomRaider installer to download the latest definitions automatically at install time. - this functionality does not exist in either application at the moment, but I like the idea


Because you have not had to add numerous tables to the existing def files yet. When you are ready to add for example, 223 tables to 53 ROM defs you will have a very clear understanding of what I'm on about. How would you add the Fuel Pump Duty table addresses to all existing defs now (careful how you answer as you might end up agreeing with me )?

oh, and I never said or implied the database is closed, etc. etc... I'm all for open source or I wouldn't be here.

Absolutely not, that is the whole point of the Alpha branch.



Scour != Click the appropriate branch, click zip button. Provided they don't have any uncommitted XML to worry about overwriting.

Or in the future, click an update button in RomRaider.

(Both of these scenarios is where the three definition levels (locked, additive, and override) we were discussing in PMs really come in handy)



I have an automated system set up for defining tables in my patches when porting (will be released after some restructuring). It doesn't use/need a database. Is there any more to this than scaling sets and languages?

First off, I'd go through the process of defining the base in the Alpha branch, and get input from others. Once finalized, it gets put in the appropriate Beta BASE xml. Then find addresses using IDA or ScoobyRom. Then my application scans your output from IDA or ScoobyRom(not working yet) for the appropriate table name, then references to that table template in the appropriate BASE, and spits out the per-rom xml



Great

Just a suggestion, tweak numbers to suit competence and availability of users.

Even if all of the files are always generated from a DB or patch tool, or whatever, they should be committed on each update such that someone can quickly and easily see exactly what changed/didn't.

In terms of database updates, those would be done with SQL scripts which, in the professional arena, be checked into a repo too. Ideally it should be possible to build the database from a set of sequentially run scripts that include the base and all updates.

It's always about repeatability and distributed information.

My 2c.

Fred.

This misses the point of a casual hacker working with a single file and developing it against their car. AFTER that it can be expanded/spread to other files as required. Being able to work from a base, record comments in commit messages, and so on, is gold.

I knew that was going to be your answer. I could have written it for you. Which is all fine, but you still have to touch every single existing file, figure out where to insert the new table info and re-write the file. It's just cumbersome from my perspective...
In the end we achieve the same result, just with different tools. I don't understand why the opposition to using a database there are many other benefits if you need to search for related info amongst many ROMs or tables, databases are fast, searching files is slow if it matters.

Thanks, that's what I've been trying to get at. The Logger SQL database is that way now. I just don't have a complete set of tools, only add and update at the moment.

Is that as a no, there aren't any more relationships (that can't be pulled from xml data) besides scaling sets and languages?

Unless there are, I see it as an unnecessary complexity to use it as the primary store of data or an integral part of the definition workflow. As an optional tool, sure, its fine.

In my opinion, the definitions should be the primary database that contains all information, relational or not. To do otherwise is to deprive the application of information.

Regarding speed, it doesn't really matter much to me. If you're going to do a big definition, you'll have plenty of time on your hands. Perhaps efforts would be better spent improving the speed of RomRaider itself.

Speaking of the speed of RomRaider... I'm just gonna throw this out there... what are your thoughts on running RomRaider on the database instead of XML? I could understand using a database as primary storage for development if the program actually used the database.

All this discussion has got me thinking about updates including Base.. Is there a way to implement updates that just add the extra parameters to the existing Base or folder for those who have patches?

Dale had mentioned an idea from Colby in regards to this, and I'm completely on board with it. It's great for testing and advanced users.

RomRaider would use three directories for definitions.
1. Official release - folder/files are read only, any official updates go here.
2. Additive - add any xml here and it will add to the official release, but never override it.
3. Override - add xml here and it will override the official release.

In regards to patches, if you're speaking of modified roms.. Hopefully anyone who makes them submits them through Git, or someone does it for them.

If anyone working on definitions has any questions about Git, join #romraider on irc.freenode.net

Patches as in purchased ie: Tinyrex LC, FFS and other Rom versions with unique ID's like SPX (I believe is the name) etc. that use EcuFlash for editing.