RomRaider

Ages ago I had some trouble with what I was playing with because the subaru logging stuff was like a small dog trying to hump your leg - incessant. This was pretty much a road block to me making further progress with the app itself. I've hung around just to help out with technical direction since then, for fun. What I'd like to see, for my purposes, but also just for general quality of operation for other plugins, is all logging implementations to be first class within the app.

This would need a better way of choosing what was logging and what wasn't. I think it's reasonable (the only reasonable thing?) to still default to trying to connect to subaru stuff OOTB, however it should be possible to disable that and configure something else instead.

To facilitate this a decent connection manager would need to be written for dealing with which plugin gets which device when. Automatic device detection etc can still be done, but what's found would need to be intelligently shared between implementations.

Another thing that I've repeatedly read is that certain other plugins are also small-dog-like and probe everything. This is generally bad behaviour - what if there was something important on one of those serial lines and you corrupted it with your probing? There may be a technical reason why it's difficult to prevent that happening, however if not, it'd be better if such behaviour was on demand, not on boot (unless configured to be on boot).

I just spoke to both Merp and Scott about exactly this, so they know just what I'm talking about. Hopefully Dale can at least advise how to best handle such changes, if not lead the charge.

There's exactly zero urgency from my point of view for this - I don't need it at all now, however there still could be mutual benefits from working together in future. Other than me, this would be nicer from a user standpoint. Right now the way stuff connects is very "rough'n'ready" :-)

Fred.

I believe we already discussed this elsewhere. There is only one logger, and it reads from all the logging data sources.

The Logger's primary protocols are defined in the Logger.xml. If there where more protocols defined in the XML (and the appropriate classes added) then other protocol connections can be made. Yes the Logger expects to have a connection on it's primary protocol before logging anything else (like supporting plugin connections). Primarily because those supporting plugins provide little useful data if there's no reference to Time, RPM and Engine load, at the very least, which is expected from the primary protocol connection. But this can all be changed with some work.

The RR Logger does no probing on startup. Any probing that you think is occurring is the result of supporting libraries being loaded. The only way around this is to build in some control to the user to disable unneeded plugins to stop the loaded of those libraries, oh wait, there already is...

I agree that there's more work to be done with the Logger and anyone with time can dig in and contribute such updates. As always the source has been available since the beginning of the project. I have a few of my own updates to add such as support for CAN bus which just keep sliding due to time commitments elsewhere.

Let the coding begin!

This is one aspect I never delved into. I did have issues on Linux with serial connection reliability, but never dug in. It wasn't high enough in the queue for me.

That said, I'm interested in the proposal from an architectural standpoint. A more detailed description of proposed changes would help.

Thanks for the explanations, Dale! :-)


May well have been, apologies for not recalling.


Seems as though, once restructured, app defaults with config overrides might be more appropriate?


I take it gets the classes from there? I've not looked. Some sort of plugin loading/registry setup would be ideal, and if the plugin jars/deps are embedded whole (not unpacked) then you will gain control of when their code executes and gain the ability to simply not load non-64 capable plugins when on 64, etc.


Time, maybe, but RPM/Load, they should not be required minimums IMO. You can get time from the runtime/system, too, if you're talking about live logging. So even that isn't required.


Ugly disgusting libraries :-/ Taking those bulls by their horns seems like a very good idea. "Warning: Loading this plugin will cause your serial ports to be raped and pillaged, if you have sensitive devices attached, remove them first". :-)


Tell us (ignorant non-user(s)) more?


True, the rendering performance/arch isn't at all suitable for my needs, it just can't keep up. But that battle can't be fought until this bridge is crossed :-)

Fred.