Driver Sharing

[mustangcoupe]

So I was sitting here today thinking about the CT family we have. And how some people use one software package and others use another. Most of these packages have a way for users to create a driver, plugin, widget or whatever your package calls it...

And Yes I know it wont be plugin play, but I was thinking of asking Dan for an area in the downloads section for User created Drivers. Where we could post the driver in it's raw uncompiled state, and they could be modified for other applications or HA software packages. I as a non professional software guy learn from reading, and stealing code from others. This would be a great help to me, and we might even get mew drivers for other packages that might not have them yet. This would be for user created drivers ONLY I am not asking any app to disclose their base driver sets or the ones which are not free.

So I am asking am I on the right track here?

 

[123]

Typically, driver authors will post their work where it'll get maximum visibility by its intended audience. Normally, that'll be in the forum of the driver's native HA software. Cocoontech is unique because it a gathering place for users of many brands of HA software. An "HA Driver Central" could work if authors are diligent and remember to post their work here and in their native forum.

FWIW, you can read the source code (VBScript) for all Module-based Premise drivers. The XDO file is in XML format and contains all classes and methods. Use a text editor that understands XML formatting (XML Notepad 2007 is not helpful) and you can spot the methods easily enough.

I'm in favour of the idea but would not participate since all of my drivers are already posted in Premise Downloads.

 

[IVB]

I don't know squat about drivers, but would that really help? Well, maybe it's b/c I use CQC, but it uses CML, which is a proprietary OO language. I'd think it would be simpler to just read the protocol than try and learn then reverse engineer that.

FWIW, anybody can look at 99.99% of every CQC drivers source code, i think there's only 1 encrypted one (C-Bus).

 

[123]

I don't know squat about drivers, but would that really help? Well, maybe it's b/c I use CQC, but it uses CML, which is a proprietary OO language. I'd think it would be simpler to just read the protocol than try and learn then reverse engineer that.

FWIW, anybody can look at 99.99% of every CQC drivers source code, i think there's only 1 encrypted one (C-Bus).

Sometimes the device's documentation is insufficent and doesn't reflect its true operating characteristics. I recently experienced this problem with Weeder's WTDIO device. Seeing how someone else handled a device's operational quirks can save a great deal of development time.

You can read a (module-based) Premise driver's code with nothing more than a text-editor. But, admittedly, it is easier to understand if you load it into Premise.

The source code for a CQC CML driver is visible if you load it in CQC. If you don't own a license, the trial version (understandably) imposes a 30-day time limit for exploring the driver's code. This has been my experience but please let me know if there is a way to view a CQC driver's code without CQC.

 

[hucker]

Have a place for driver source code/binaries seems like it would have value, but as ivb stated most drivers have a logical home at the mfg's site.

The cost is low though to have a thread with links to drivers or drivers them selves. I have some .net code that can talk to a Brultech 1240, that doesn't belong to any native system. I would drop it in here in a flash.

 

[mustangcoupe]

Chuck

Thats exactly what I am talking about... this way all platforms get to use it. I was hoping to have a repository like premise has for drivers. but one big one for everyone to share