Official Pre-2.4 beta discussion thread

[Dean Roddey]

So, we are now working towards a 2.4 release. As we've mentioned in a few other threads, we are going to be taking a somewhat different approach on 2.4. Instead of just working on all the changes for the whole release and then starting beta testing, we are going to do the major changes one at a time and release a set of betas along the way, and then probably one last chunk of smaller things at the end.

We feel that this will have a number of benefits:

• Faster Access. People are always waiting on this, that or the other feature. The bigger the feature the more people are probably waiting for it. So this gets those features out ASAP.
  
• Better Testing. People are getting one new major feature at a time, so it gets beat on right away. If there are issues, it's all still fresh in our heads and it's more likely we'll get the fix done more quickly and more correctly, and it's far more likely that any problems are in the last or last few new features that came out.
  
• More Stable Releases. Not that our releases aren't generally quite stable. But this just ensures that the biggest, most complex changes for each release get way, way longer testing time than would normally be the case in the standard way of doing releases. The bigger the feature, the earlier it's done and the longer it's in the field getting proven before the formal release.
  

We never can say exactly that we will do this or that in any given release, since circumstances almost always push us around. But, certainly there are a few key things that are going to get into 2.4 and will be done early. Those being:

• Driver initialization changes. Drivers need to survive a failure to initialize and keep trying, else they can fail to load when certain system features are not ready by the time CQC's service comes up, which does sometimes happen. This is a major issue for us now, and it will get addressed first. Actually, I've already got it working.
  
• Driver 'reconfiguration'. The ability to reconfigure a driver instead of just having to remove and re-load it is somethign that's much needed. It makes for fewer mistakes and more convenience, since the install wizard can just offer you the previous values as the defaults and you can change what you need to change.
  
• First cut at a 'Logic Server'. This is too big to describe in a sentence, but it's been discussed elsewhere. This will offer a huge benefit in terms of creating new fields by doing operations on the values of existing fields. The existing variables driver will be extended to support this.
  
• Protected drivers. We have some situations where drivers cannot be done because the folks who license the interface won't allow that interface to be seen by anyone who hasn't signed an NDA with them. Since CML is a virtual machine language, all the drivers are shipped as source and compiled on the fly when loaded, so it's not possible to hide the contents of CML drivers. We will provide a means for driver writers to encrypt the driver package when they export a driver (which is why CML was never stored as just text, because it needs to be able to support this.)
  
• On Error action event. The addition of an OnError event in all actions, which will be invoked if an error occurs during the action. This will allow you to deal with things like drivers not being ready and whatnot, and not get our standard error popup. So this will be a huge deal for creating professional user interfaces in particular.
  
• Elk/Omni driver updates. It's been a while since these drivers have really been revisited, so we'll be taking another whack at them, to get new features into place.
  
• Media repository updates. We need to support some things like a few types of on the fly categories (such as "All from artist X" and that kind of thing, and fix some things wrt to how artist/title names are dealt with for sorting and first character access.
  

Those are the big ticket items we fell have to get into 2.4. Of course, with this new scheme of doing things, if at some point along the line we felt it necessary, we could just do a 2.4, and push the other stuff along to 2.5, since at any one point we may have a nice, stable release that has something that needs to be formally released. But, most likely we'll get all these done before we do a formal release.

[Dean Roddey]

On the first item above, the driver initialization thing... This could cause some problems. Most drivers would not make any assumptions that the initialization would only be called once, but some might. This could cause problems if they ever failed to init the first time and CQCServer starting trying it again. I can't think of any that would have this problem, but it's something to watch for, and you'd never know it unless the init failed and that's very rare.

Previously, logging during init was not necessarily done conditionally, based on the driver verbosity level, since initialization was only ever done once. So many drivers may have non-conditional logging. If one failed to load, it could log a lot of messages if you don't notice it for a while.

I'll check all our shipped ones to make sure they are conditionally logging and have no issues with multiple initialization calls, but for folks writing new drivers or who have current ones not in the release, they should check this and make sure they are good on this front.

One nice thing is that the verbosity stuff now is useful in initialization failure situations, since you can now turn on verbosity if you see one is failing to initialize and see what's going on. Previously it wasn't of much use since the driver wouldn't show up until it was already initilized and, if it failed to init, you never had a chance to set the verbosity.

It will retry the init every 10 seconds. This is just a fixed interval for now, you cannot set it like you can for polling and reconnect time.

It also means that CQCServer comes up a lot faster now, before the drivers are initialized, since that work now happens asynchronously on the driver's own thread, as the other callbacks do, whereas before CQCServer initialized all drivers before they were made visible. So there's more chance that you can get up and going before the drivers are available now. This shouldn't be a problem in general, since the same really applies to connecting to the device as well, but it is different behavior from before.

In the test harnesses, the initialization is still just done once and it either works of the test harness complains and stops the debugging session. It doesn't really make much sense to do otherwise while developing the driver. If it fails, put a break point in the init and run it again and stop and see what's going on.

[1080iAddict]

Dean,

The following may not be on the list for 2.4 or 2.5, but at some point should be considered in my humble opinion.

I currently have 3 touchcomputers and 5 other regular PCs running CQC. That makes 8 computers - and my system is still growing. It is a huge pain in the arse to upgrade each of these computers every time we get new CQC version.

The solution could be either 1) allow a widget button to be pressed (that we could creatively hide on the interface somehow) that will be the equivilent of a typical software menu item to "check for update and install update"; or even better 2) allow the update to be pushed to clients via the master server, i.e., "push update and reboot client" (edit: probably wouldn't even need to reboot.... just 'push' and restart cqc service). Either way, the process should be automated with the option to push a new version out to all clients at the same time when we ask it too.... or to periodically check and do it automatically.... like windows update.

The bottom line is that it takes me a few hours hours to collectively go to each client to do these upgrades, when it 'could' only take 5 minutes. This is, after all, automation software we are all using!

Anyway.... just something for you to consider for "The List".

[Dean Roddey]

Yeh, at some point we'll need to do something on this front. But that's a big one to undertake, way harder than it sounds, because there are so many ways it can go wrong, and it's a whole system that has to be updated, unlike Windows Update which ony has to update each machine separately without worrying about any other machines.

[ToyMaster458]

Yeh, at some point we'll need to do something on this front. But that's a big one to undertake, way harder than it sounds, because there are so many ways it can go wrong, and it's a whole system that has to be updated, unlike Windows Update which ony has to update each machine separately without worrying about any other machines.

In the mean time I would just be happy with a way to automate the installation with either an ini file or command switches.

[ToyMaster458]

• Protected drivers. We have some situations where drivers cannot be done because the folks who license the interface won't allow that interface to be seen by anyone who hasn't signed an NDA with them. Since CML is a virtual machine language, all the drivers are shipped as source and compiled on the fly when loaded, so it's not possible to hide the contents of CML drivers. We will provide a means for driver writers to encrypt the driver package when they export a driver (which is why CML was never stored as just text, because it needs to be able to support this.)
  

My only concern is that Charmed Quark has a way to decrypt these drivers in the case the original programmer goes to the moon in a balloon and can be taken over by another programmer that has the proper NDA in place.

[Dean Roddey]

In some cases we could do that. In others, it wouldn't be legally possible perhaps. It might be that a company implements a driver for their stuff, and decide at some point to pull it. It would be their right. It's not likely, but it could happen. Otherwise, yeh, we could get back to the original source code if that was necessary.

[zaccari]

You're not going to reverse the encryption though, if they pull their driver. That'd be way silly. Personally I'd much prefer that encryption not be supported except in the NDA type situations. I really think we all benefit from people picking up previously dead drivers and the ability to start with sometihng already existing as a basis for a new driver.

Russ...

[Dean Roddey]

Once the ability is there, we can't stop anyone from using it, but it is really intended for the support of drivers where the source code cannot be legally exposed.

[scott]

Not sure if that is the intention, but it sounds like this encryption thing will be used as a vehicle to provide drivers for payment.
Too bad, since I like the openness of the CQC driver system, and created an open source environment, where everybody cooperated.