OtherTuningSoftware/GuideLines (2004-06-25 00:32:33)

tuningsoftware developers brainstorm on this page to avoid duplication of work and keep the design nice and maintainable

I find it likely that for the tuning and displaying software we need to maintain (hopefully just) 2 independent codebase for the low level stuff: GUI, comm (RS232, TCPIP) because of technology and resource usage reasons (large thanx to microsoft innovation and standards abuse.


Common infrastructure includes: (see OtherTuningSoftware/CommonInfrastructure)

To make the above (realistic) scenerio maintainable, we need to split as much of the logic to interpreted code (txt, xml or config files, whatever you call it), that only needs to be maintained once for all branches.


Low level stuff:

We try to shring it as far as possible.

Probably separate branches are reasonable for these:


platform for the main branch

I assume there will be at least another branch besides the main branch (eg. for loseCE machines maybe?).

For the main branch, Java would be a better platform than C or C++, because of development costs.

Java improved impressively in the last 9 years, and became the nicest option for most non-realtime tasks. However it still uses relatively much resources (that much resources available on most desktops an notebooks, and probably most PDA).

C# is not based on an industrial standard, and it's advantages don't come near it's disadvantages (if we think globally and long term). But a C# branch (for the low-level stuff of course) can still be maintained easier than a similar C solution. Whoever picks the task will choose.

This is not the place for programming languages holy-wars, we just want a better usable, maintainable tuning software with the minimal possible total work that covers most platforms.


Brainstorming - the rest of this page:

looks nice:

http://thinlet.sourceforge.net/overview.html


XForms: common layer for describing parameters

It's quite self-explanatory, that the data manipulation and the

GUI implementation must be decoupled to a large degree.

We already started it on the lowest level by naming config variables and arrays and tables that can be filled in several ways.

I found that XForms does the decoupling almost _exactly_ as we need.

There are implementations for all kinds of systems (including browsers and PDAs too).

It does not prevent us to make our full-featured widgets for some special platforms (java, GTK, win32) if we like.

Anyway, XForms should boost the tuningsoftware issue. Please think about it, and tell your ideas.


See also: