Official RIVA thread

[Fonceur]

Also, the image files that templates ask me to draw are almost always many multiples of the size they really need to be.

I seem to remember the images already pre-scaled to multiple of 16 or so, at least for the Media browser when used in "small images" mode... Which is where most of those multiple images from bigger ones would happen... And I think Dean expanded the logic to the selected item from that Media browser.

[brianmount]

Pehaps Commander Vimes can chime in on what he's using now. It's true that I used to get nice small media images for movie thumbnails. But now, due to whatever template he's using, I wind up getting Web image widgets that are very large. Maybe whatever produces those doesn't have the automatic scaling feature.

[Dean Roddey]

The CAB has a setting for large or small cover art. He may have it set to large and just needs to put it back to small. The Media Image widget also has a similar setting.

[SamVimes2]

Web image widgets don't have a scaling option. That's only on the CAB.

[Dean Roddey]

Oh, so you are using the Sage thing or something like that? If so, it'll have to provide some sort of means to request small vs. large art.

[SamVimes2]

It's the SqueezeServer driver. The author suggests centralizing/reusing the existing scaling functionality, since many drivers might want to use it...

[Dean Roddey]

So to move some general discussion over to here...

We have the issue of the RIVA clients and the fact that they only stay connected to the network for so long then they go to sleep. That drops the connection and the RIVA server drops the associated session. When the RIVA client wakes back up, it has to reconnect and it's back to the base template again.

This obviously isn't going to be acceptable long term, so something needs to be done. I made a suggestion which I think will deal with that cleanly, and it will dovetail nicely with the upcoming requirement to start enforcing the client counts and such. The idea is that the RIVA server will be explicitly configured to always be running some number of sessions.

The benefit is that it's always there. There's no need to crank it up with the RIVA client connects, and if the RIVA client drops the connection, the RIVA session on the server just stays where it is. When a RIVA client connects, the server just forces a screen redraw to make sure that the client is up to date, and that's it.

There are certain gotchas of course, since nothing is free. It does mean that you can't drive what's displayed based on the template configured in the user account that you use to log in. That will be part of the RIVA server configuration. As long as the RIVA client logs in under an account that is of sufficient privilege to run the base template (remember each template has a minimum privs level), then it will be allowed to connect to that already running session.

It also means that you cannot use environmental variables on the RIVA client to drive RTVs on the session, since the session is already running. So you would have to configure those environment RTVs as part of the RIVA server configuration when you set up each session.

There will stil be a one to one relationship. I.e. only one RIVA client at a time can connect to any given session. I'm assuming that the sessions will be named and you'll use the name in the login request to indicate which one you want to attach to. If it's alread in use, the login will be rejected as already in use.

There's no need to have any sort of 'session id' because the configured (and persistent) name will effectively provide that. It doesn't matter if the RIVA server goes down and comes back up while the RIVA client is asleep. The RIVA client will make no assumptions about what has happened while it is gone. When it connects, the RIVA server will force a redraw of the whole template, which will effectively make the RIVA client get back into sync with the state of the state and any images and so forth.

And of course since you are explicitly configuring all RIVA sessions, then we know how many client licenses are to be allocated to RIVA clients. This does though mean that those client licenses are always in use. Just because no client is currently connected, the session is always running, and will eat up a license slot. The payoff is that have quick reconnection and can pick right back up where you were before. And also you avoid any wierdness that would inevitably come with trying to dynamically allocate client slots based on what is actually connected at the time. It would be quite difficult to do in such a distributed system. For the pro folks that means that, though perhaps a somewhat higher cost, much more reliability and consistency.

The same sort of configuration may be done for IV clients as well. Not that they would all be pre-running sessions like with RIVA, but configuring which hosts you want to allow to connect as IV clients. Though it makes for a less dynamically configured system, it does provide some security benefits and centralized system configuration where it can be completely backed up and restored and again makes for a very comprehensible allocation of client license slots that is simple and easy to understand.


So, anyway, that's my suggestion. How does everyone feel about that?

[potts.mike]

Was there ever a decision made on passing web widget information over to the client. This way if I device is able to support it web widgets could be used. I am pretty sure that the iOS SDK allows you to embed web windows in apps

[Dean Roddey]

Was there ever a decision made on passing web widget information over to the client. This way if I device is able to support it web widgets could be used. I am pretty sure that the iOS SDK allows you to embed web windows in apps

That's not something immediately planned. We'd put any RIVA time for now into just making more basic improvements/changes, such as discussed above I'd imagine.

[SamVimes2]

For what it's worth, I like and support the direction above.