Posts: 40,483
Threads: 491
Joined: Aug 2002
But if the network connection is down for an hour, it's irrelevant what we do, since you couldn't be doing anything while the network connection is lost. I think that the main issue is that the network connectively blinks out for four or five seconds and that causes the socket connection to be dropped between the client and server. This happens at a level below what we can control.
But, if we allowed for some way for the client, after loss of connection, to try to reconnect to the same session on the server, which it would keep open for, say, 15 seconds worst case before giving up, that would allow the client to reconnect to that same sessiona again after an intermittent wireless network failure. The server would just completely redraw the screen to make the client get back into sync again where it was before.
That's something that's probably reasonably doable and I think it would address most problems. So you might get periodic 'please wait' type of dialog boxes as its trying to get reconnected again when the connection is lost. But it would come back to where it was, as long as it can reconnect in some fairly short time.
Dean Roddey
Explorans limites defectum
Posts: 362
Threads: 10
Joined: Sep 2009
Do I understand your suggestion to be that when the client logs in it receives a session token of some kind, and then later on, when logging in again after a dropped connection, the client can pass that token and "claim" the session again? That sounds like a good idea.
Posts: 362
Threads: 10
Joined: Sep 2009
We were talking about the leading/trailing space issue on the iPhone client thread, but perhaps it belongs more properly in this thread. I'm not sure it's really right to count all whitespace when breaking lines and centering. Let's say that the user's multiline text string consists of 44 characters: a space, an A, 40 spaces, a B and a space. The text box is narrow enough that my RIVA client decides to break up the A and B onto separate lines. When center- or right-justifying the text, which characters should the client count as part of each line?
Posts: 40,483
Threads: 491
Joined: Aug 2002
brianmount Wrote:Do I understand your suggestion to be that when the client logs in it receives a session token of some kind, and then later on, when logging in again after a dropped connection, the client can pass that token and "claim" the session again? That sounds like a good idea.
Yeh, something along those lines. It would stay open for a while on the back end. Not a long time, but long enough that short losses of connection would cause a reset. If you try the relogin and it fails (probably with a 'bad session id' if it's been too long), then you'd go back to scratch with a regular login (though those two things could be done in one call really, if you get back a 'bad session id' but the login info is good, you'll get back a new session id and that becomes the active one. Doesn't matter per se to you which happened. You would just flush any stacks since when you connect you'll just get a full redraw.
Dean Roddey
Explorans limites defectum
Posts: 40,483
Threads: 491
Joined: Aug 2002
Breakage, I would think, would always be at the first space after the last thing on the first line, on any platform, right? If so, then those other spaces would be relevant on the second line for left or center justification. They would effectively do nothing for right justification since they wouldn't affect how it's position (being to the left of the text.)
Ultimately, underneath a number of nested hoods, I use the Windows text drawing stuff, so however it handles justification in multi-lines is how it should be done, in order to be consistent. I'm guessing most platforms would tend to do it kind of the same.
Dean Roddey
Explorans limites defectum
Posts: 362
Threads: 10
Joined: Sep 2009
But if you had the string "A A", and broke it on two lines, you'd expect the two A's to line up no matter what justification you use, correct? If we left the space as part of the second line, they would not line up for left- and center-justification. I'm pretty sure we ought to excise the space in this case.
In this application I'm doing my own word breaking and alignment (Apple's version works a little differently from Windows in certain ways, so I had to roll my own). So I need to figure out what rules to use. I guess I'll just keep changing the rules until people stop complaining.
Posts: 40,483
Threads: 491
Joined: Aug 2002
You can quickly check what should happen using the Interface Designer. Create a static text, set the justification, allow word wrap, and then start pushing spaces between two A's with centering. I think it will keep the spaces but maybe it reduces them down to a single breaking space, I've honestly not really looked at that in detail for a long time.
Dean Roddey
Explorans limites defectum
Posts: 362
Threads: 10
Joined: Sep 2009
How does the PlayWAV command work? I see that, when Rob puts a sound in his template, and I trigger it, I receive the string "C:\Windows\System32\8point1.wav". I'm assuming that I pass the string back to the image server to fetch the data, but I'm unclear on the details. Is there a prefix to be added to the string (akin to CQCRepo:  , effectively creating a third data cache? Or am I totally off base with the image server concept? Thanks.
Posts: 40,483
Threads: 491
Joined: Aug 2002
There's no third cache or anything. My thinking would be that they would just arrange to have the sounds desired on the target device and provide the RIVA client a simple path mapping (e.g. C:\MyWAVs\ becomes /CQCWAVS/ or something like that) to map from the path they provide to wherever they put them on the client.
Some of these files are large, so we can't transmit them every time, and I'm kind of loath to introduce another cache. And also the RIVA server may not be running on the machine where the WAVs are either.
If it is deemed just not workable to do it this way, we can consider another cache. But hopefully we can avoid it.
Dean Roddey
Explorans limites defectum
Posts: 362
Threads: 10
Joined: Sep 2009
Hmmm. But how would a template designer get their sound files onto the iPhone? I don't think that's workable in the heavily regulated iPhone environment, where each application has its own sandbox file system. And I bet that many mobile and small-footprint devices will have a similar problem. Smartphone users aren't usually provided with a file explorer application. Maybe Android will be able to do this, but nobody else.
Further, any new client would need to be configured before use. If Rob's iPhone-loving friend comes over to his apartment, and Rob wants to show him his cool iPhone-controlled CQC system, he can't just give him the host, port, user name and password to put into the phone. He also has to load up the necessary sound files. No other aspect of RIVA currently requires this -- images, for instance, are pulled from the server as needed.
Perhaps I'm missing some clever approach; let me know if you have any suggestions. But it seems problematic. You note that the RIVA server may not be running on the same machine where the sound files are. But that is also the case with images, correct? Maybe you're imagining the WAV file being used to retrieve songs, large audio files, etc. that would reside on a separate A/V machine. I can see how that might be a problem. I was envisioning things more like system alert sounds, beeps and clicks, things to make the user interface nicer.
So I heavily favor the creation of a third cache of opaque data that the image server serves from in response to appropriate request paths. This would let me use sounds on the iPhone. And I may also be able to use the same mechanism for font downloads: when the client gets a request for a font it doesn't recognize, it asks the image server for Opaque::Fonts/TheFontName or some such, then installs the font locally. Just a thought.
|
