Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Version 5.0 thinking out loud
So, more to just get my own thoughts down than anything else, here is some thinking out load about the 5.0 version. We pretty much know what we intend to do, it's just a matter of how it's sequenced in order to make things go the smoothest. Of course, this is now, and the realities of the moment may cause some deviation. The problem with the future is that it hasn't happened yet, as they say.

The changes involved in 5.0 will be far more than the already considerable changes for the 4.4 release, so I'm assuming we'll call it 5.0. However, before anyone freaks out, unlike the 4.4 changes, these will almost all be internal architecture things, not the sort of stuff that caused the breaking changes in 4.4. So they won't be visible to end users except in the form of a better, more capable system.

There are a small number of items on the list, because they are all sort of stupidly difficult, and it will be challenging enough to take just these on.
  1. Implement real inertial scrolling, i.e. draggable and flickable.
  2. Make the interface system scalable (meaning in terms of scaling the size of the widgets to fit available space.)
  3. Rework the guts of the interface engine in order to prepare for a new RIVA system (RIVA 2)
  4. Implement a new RIVA 2 server
  5. Implement a new C++ RIVA client as a test vehicle
  6. Implement a new RIVA client for other platforms (details still in flux on this as to the approach.)
  7. If absolutely necessary, resurrect the RIVA 1 server over this new scheme.

So, clearly this is a very user interface oriented release. And it will mean that back end improvements will take a (no pun intended) back seat for the next release cycle. The obvious reason for this approach is that, despite all the hard work, we are still lacking on the front end on non-Windows clients. And the front end is, for better or worse, so much of the selling point of a system. The back end, though obviously there can always be improvements, is pretty dang hard core these days, so we just need to get things more evened out. Then we can come back to back end stuff.

The driver behind doing a new RIVA client is that it is just not practical to expect XML GW based apps to approach the power and flexibiltiy of the IV system. We will continue to support the XML GW of course and improve the room config info and the like, for those who want to use it. But it will never replace the power of the interface system. And, since we can auto-generate templates based on the room config, that means that a simple to create interface will continue to be available. As long as we have a RIVA client that is solid, then that will always be a superior solution, since it is both easy to generate and the output can be infinitely customized as well if desired. And of course the second item on the list will significantly improve our ability to auto-generate nice templates, since we will be able to make use of scability to support related resolution.

In our case, at this point we would drop our XML GW based app since the argument for it would no longer exist. It was only started on because of the lackings of the existing RIVA system, and partly to get some experience in the Android development milieu. If those lackings are removed, there would be no justification for continuing the GW app, though the source will be available and anyone who wants to do so can continue to develop it if they would like.

At some point down the list, either #2 or #3, existing RIVA clients will stop working, and there won't be any workable clients until I get to the end. That's just the nature of the beast for this release. But, it's not like there are a bunch of other features in the list anyway. There'd be no reason for you to need t move beyond step #1 anyway (or step #2 if it turns out that doesn't break existing RIVA clients.) You'd just wait till the end and upgrade.

I will end up splitting the code base. If issues come up that absolutely have to be fixed, I'll fix them for a 4.4.x release and then make the same fixes (if it's even still relevant) in the 5.0 code base. I certainly won't do any non-trivial new features in the interrim, because I'd have to make the changes in two code bases. So I won't be able to just throw in stuff for folks on the fly for a while during this work.

Just some comments on the steps...

Real Inertial Scrolling. What we are doing now is just flick type gesture support. You can't drag anything by way of gestures. This is because we had to initially support something that the RIVA clients could deal with. Obviously getting rid of this limitation in the IV and RIVA systems will be a big part of this work.

This may be limited on the Windows platform to multi-touch systems only. Non-MT systems may just continue to support flicks. This is because we would change the multi-touch systems over to using inertia from the OS itself, which means everything would essentially be a drag type scroll, it's just that the OS will continue to send out inertial scroll messages i fyou lift your finger while dragging. So a fast movement and release effectively is a flick, but it's really being done by inertial scroll msgs. This functionality won't be there on non-MT systems and I don't want to have to try to implement it. Ultimately, a big part of this work will be decouple the IV engine itself from scrolling, flicking, gesturing, etc... capabiltiies, so that each type of client can do what is available and/or native feeling.

Initially I'll add this to the regular IV, and keep flick support in place for existing RIVA clients in the meantime. So it'll initially only work in the real IV, but that'll let us get this really nice feature out there without breaking RIVA clients.

Scalable Interface. Clearly this will be a very useful and powerful feature. It will make it vastly easier to support multiple, closely related screen sizes of identical or very similar aspect ratios, using a single set of interfaces. And, also to support overlay areas of similar shape within screens of more disparate AR as well. Anything that reduces the redundancy of interface creation will be a very good thing, in this world of ever more client screen sizes.

Obviously there are limits to this. Things will get grossly distorted if the original aspect ratio is different from one that is scaled to at viewing time. And in order to keep things reasonably sized when scaled down, you will have to spread things out more than you would otherwise at higher original resolutions, so you do also lose some 'info density' as well in some ways. And depending on really tight, pixel level alignment of things could be tricky during scaling as well.

But still, it will be very useful. Some of the widgets of course don't have to actually scale anything, such as the list oriented widgets. They just show more or less content as their size changes. And we'll probably do 3 and 8 patch image type widgets that can grow the widget itself without having to scale the images, so that fidelity is preserved. These would tend to be used underneath those scrollable widgets, for instance.

It may be that, at this point, RIVA clients are dead until a lot more work is done and I come out at the bottom of the list above. It is possible that the existing RIVA clients can handle this change without any real effort. If so, great. If not, I and the existing RIVA clients aren't likely to put in any big effort for an interim solution that would only last for part of a beta cyle. If it turns out that the RIVA clients can't deal well with this change, those folks that need RIVA clients will just have to stop at the previous beta drop and wait for me to arrive back out of the long, dark tunnel.

But since this scalability is obviously something that the new V2 RIVA system will need to support, either way it needs to be done before moving on to the next steps so that support for scalability can be a fundamental part of the new scheme, and therefore dealt with as efficiently as possible.

[INDENT]* In actual fact, as I think about it, I may just incorporate this into the next item, since otherwise it may end up being too much work that would just turn around and be reworked again.[/INDENT]
Dean Roddey
Explorans limites defectum
IV Guts Rework

The way that the new RIVA system will work will be fundamentally different internally. The goal is to get rid of all of the issues that the RIVA 1 scheme has. Not to dis it, since it was a good first effort and served its purpose. But we need to make it solid in the face of flakey wireless networks, move user interaction and drawing to the clients so that it's more responsive and more native feeling, minimize the traffic required to keep the client and server in sync, and apropos to this item, get the IV engine such that RIVA isn't a bolt on but that the regular IV and RIVA clients can work through pretty much the same sort of interface (though of course the real IV will be local and at maximum speed still.)

So the IV engine will be highly reworked, to separate out user interaction from drawing, and to implement that drawing in a form that will be very conducive to supporting RIVA clients efficiently. So the interaction of the IV engine with the RIVA clients won't be at the level of just redirecting drawing and user input messages (where even the RIVA server doesn't know the context of what it's sending to the clients), but at the IV engine level directly. Clients won't need to know specifics of the widgets, but they will know what the widgets are, where they are, attributes about them, be told how to draw them, and what types of interactions they support.

Widgets will be re-jiggered into a set of formalized visual 'states' (press/unpressed for instance for buttons.) And the drawing will be in terms of a set of abstracted drawing commands for each state. The drawing commands will refer to a set of key=value attributes that each widget will have associated with it (of the sort required for visual display or to control whatever visual/interaction aspects that RIVA clients could need, visibility, can it be clicked, is it a list type widget, etc...)

Other than upon the load of a template, most of what will flow between the RIVA server and client is just the updating of these attributes where that is required, and the changing of the state of the widget. RIVA clients will be able to do all of the drawing themselves, and will have a free hand to scroll the contents of scrollable widgets as long as they let the server know what the new scroll positions are. They can do press/release type emphasis themselves as well, just telling the server that the state of the widget has changed from this to that or a named attribute has changed. Most of the time the clients will be doing things themselves, except for the actions invoked which will still need to run on the server.

The IV engine will also be updated to use the same abstracted drawing commands that it will send to the RIVA clients. This insures that what the RIVA clients are told is correct and it will avoid having to try to keep two different views of how to draw widgets in sync. Each widget state will have an associated list of these commands, to draw the widget in that state.

This will be a very fundamental rework of the IV engine, and it will probably result in my institutionalization. But, it will make all the difference in creating a new RIVA system that doesn't have the issues that the current one does. On the outside though, nothing will have changed as far as you guys are concerned. Things will just be done differently internally.

New RIVA Server and Clients

Obviously the next step will be a new RIVA server to work in this new way. It will also be pretty fundamentally different from the current RIVA server, working at a totally different level. In some ways it'll be easier, in some ways harder. But, the above work should insure that the IV engine won't be really any different when driven from a RIVA client than from the regular IV window.

There will be significant effort put into dealing gracefully with flakey network connections. The new scheme will have a lot more recoverability, so that RIVA clients, even if they lose connection for short periods of time, can get back to where they were before. So it doesn't have to just start over again if the network glitches for a second.

I'll do a C++ reference client first to provide the test bed for the server and make sure it's working as it should and bang out any kinks. At this point I could put it out there for folks to try on Windows if they wanted, though probably not too many would yet.

At this point, if I've not died of terminal nerdiness, we can work on new clients for the other platforms. We are looking at ways this might be undertaken such that it wouldn't require a different client for each platform, but we'll see how that goes. If it that turns out not to be practical it will be done the old fashioned way.

Legacy RIVA Server

If it turns out that we both cannot figure out a way to do a single implementation that will work on both Android and iOS and we can't get the iOS guys on board to support the new scheme, then I'll have to find some way to retain the old RIVA 1 scheme for iOS for the foreseeable future. That will mean none of the new fun stuff is available for iOS RIVA but the existing clients would continue to work.
Dean Roddey
Explorans limites defectum
Have you looked at using something like Mono to develop the IV in? you might be able to abandon RIVA altogether if you can develop for all three platforms at once.
.Net isn't an option really. CQC is written in C++ and it would be beyond brutal to attempt to use .Net for something other than a RIVA client. The amount of functionality is ginormous and it would all have to be converted.

Mark is looking into some options to see what might be reasonable. I presume that HTML5 is among the options, plus some portability schemes (between Android and iOS) that some folks have made available. As long as we can cover Android and iOS in one go, that would be sufficient. I can cover C++, and would do so anyway just to have a conveniently debuggable client for testing purposes.

If such a solution also covered Windows RT, all the better. Despite what people may have thought about it first time out of the gate, it doesn't look like Microsoft is going to fold up and go home on the RT front. They appear to be prepared to keep going till it takes, from what I've seen.

Though, on the flip side, it looks like smaller and faster and cheaper full Win8 tablets are going to become more and more available, so that is good as well. I sincerely wish we could just tell people to use Win8 tablets but that's like telling people to change their religion or some such.
Dean Roddey
Explorans limites defectum
While all the new stuff is fine, at what point is attention going to be put to updated some of the older drivers - those that are most used. Specifically the ELK and HAI driver? I believe most people who use CQC use one of those drivers. I have heard it is to major to do in a minor release, but now we are talking a major release and no mention of it again.
George M
Dean Roddey Wrote:Mark is looking into some options to see what might be reasonable. I presume that HTML5 is among the options, plus some portability schemes

To support HTML5, you need to serve up a web page to collect the configuration/connection info and client code and you need to proxy the TCP connection through HTTP using something like Websockets (since HTTP doesn't support persistent/real-time connections) This could either be done natively in the RIVA server, or the CQC Web Server component could be updated to serve up the pages and proxy the socket connection. Adding this support to CQC would prevent users from having to install additional server side components like an Apache or Node.js web server.

Since the Web Server doesn't do a lot of parsing, it might be able to handle serving up an HTML5 client today, so you would just need to add support for Websockets, which looks pretty trivial. You could also just switch RIVA to a messaging scheme like webservices and forget the persistent socket.

The last piece which I didn't look into was data storage for caching images on the client. There are a few options, but some of the newer HTML5 ones may require some web server side support as well. Image caching on the client has proven to be a big help in RIVA performance.
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
The thing I would like to see is some high level automation functionality added to the system that would create some built in capabilities that probably could be used by many people. My thought is these bits of automation could be packaged as a driver and use other drivers to connect to the types of devices actually installed in various systems - something along the lines of the Irrigation Scheduler driver I put together.

Areas that I can think off off the top of my head are:

1) Lighting - managing the scheduling of light on/off, adding the ability to create scenes, ability to tie into occupancy sensors and have options on each light for what to do, providing for simulating at-home behavior when not there, etc

2) Notifications - sending out notifications of various things that have happened or are happening in the system including management of email addresses, ability to configure which notifications go to which addresses, automatic enabling/disabling of notifications under different system conditions, etc

3) Announcements - queuing of announcements, managing destinations for announcements (which rooms they go to and whether they are currently muted or not), controlling volume of announcements, allowing for a attention tone before the announcement, playing a wav file as an announcement, etc

I'm sure there are other big things like this providing pretty general functionality that would be useful to a big number of people.

All of the above can currently be done in event handlers and template code, but are pretty big jobs for any one person to put together. A general CML solution that is configurable for these areas would, to me, be a very compelling offering.
George M Wrote:While all the new stuff is fine, at what point is attention going to be put to updated some of the older drivers - those that are most used. Specifically the ELK and HAI driver? I believe most people who use CQC use one of those drivers. I have heard it is to major to do in a minor release, but now we are talking a major release and no mention of it again.

These changes would be done in the context of updating them to support the new V2 driver architecture, to the degree that that would require changes. Everything will be gotten to in time, but we have to concentrate on what allows us to stay alive, and hopefully at some point begin to thrive as the economy picks up. This product cannot remain an excuse for me to continue to live in poverty for another decade. So we have to address those things that will make us competitive and appealing to residential and commercial installers. There are obviously many things that will contribute to that, but the front end is the most (obviously) visible component and what potential customers will see first.

Obviously at the end of all this work, there will be a good chunk of time where these changes are allowed to cook, to make sure they are solid. I can take on some driver work at that point.
Dean Roddey
Explorans limites defectum
I'm in awe of the amount of product Dean has managed to produce and maintain, and taking on another huge UI/RIVA refactoring sure sounds daunting.

My thought going through the post was that a whole load of stuff in there sounded just like HTML(5). It offloads all the rendering to the client, it deals with as many fancy effects as you want as well as providing good support for scalable (aka responsive) design. And you hit all the clients for one price all at once.

I've said before that I think a key bottleneck for CQC is its inability to leverage other pieces of the technology world that are out there. There learning cover is steep and has little in common with the technologies people are familiar with.

Maybe this is more of an issue if you want to primarily go after the hobbyist market ... I could see it being different for professional installers who want a one-stop-shop and I don't know how the market share splits.

(And of course this opinion is worth exactly what was paid for it! I totally want to see Dean get more reward for his efforts over the decade+)
jkish Wrote:The thing I would like to see is some high level automation functionality added to the system that would create some built in capabilities that probably could be used by many people. My thought is these bits of automation could be packaged as a driver and use other drivers to connect to the types of devices actually installed in various systems - something along the lines of the Irrigation Scheduler driver I put together.

Certainly all those things would be quite useful. Believe me, after this 5.0 release, my UI gag reflex will be high and I'll be happy to work on back end stuff again.

I think that much of that stuff would also dovetail into the concept of another tab on the event server that allows for continuously running actions (which could of course also be CML based.) That would be an obvious place to host such stuff, and it would allow for those things to be able to inherit common useful functionality required for such things.
Dean Roddey
Explorans limites defectum

Possibly Related Threads...
Thread Author Replies Views Last Post
  Last Version for XP znelbok 1 2,079 06-30-2015, 07:42 AM
Last Post: Mark Stega
  VRCOP/latest CQC version? IVB 47 13,663 01-02-2014, 06:16 AM
Last Post: George M
  Rolling back version dogman 6 2,544 02-03-2013, 01:53 PM
Last Post: Dean Roddey
  Version 3.0 preview Dean Roddey 9 3,826 06-30-2009, 10:31 PM
Last Post: Dean Roddey
  UPB Status Error in Beta Version 2.4.26 Forefront Technologies 0 1,518 01-21-2009, 11:47 AM
Last Post: Forefront Technologies
  Driver version checking robolo 11 5,475 09-25-2008, 12:24 AM
Last Post: robolo
  Latest Version dirtracinfan 11 4,895 12-05-2007, 09:07 PM
Last Post: ellisr63

Forum Jump:

Users browsing this thread: 1 Guest(s)