Re: Stopping the browser throbber

Post #60,271 by admin 10/30/02 3:46:00 PM Reply	Re: Stopping the browser throbber What kind of business are you in? (making this a new thread to get off that 150+ reply monstrosity... ;-) Yeah, agreed on the frame/javascript issue. We're looking at several alternatives, and the one you cite (one applet with multiple page/javascript consumers) will probably be the way we go. Since ours is over the internet, the "real-time" concept seems far-fetched for some (since it may take up to a second just to sent one piece of data), but as mentioned elsewhere in this thread, it comes down to what the decided acceptable delay is (whether that's sub-second or one minute or whatever). The guys supporting the network infrastructure were a little nervous about the concept, and we had to do some extensive performance tests to show that the connections being held open didn't cause major issues. There's still a concern as the number of users gets higher, though (like I said...we don't have thousands, fortunately). From what I've read in this thread, it appears that you're implementing the back-end very similarly to the way I am. Spooky. Dan Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #60,273 by dshellman 10/30/02 3:51:58 PM Reply	Re: Stopping the browser throbber Hm....good question. I'm not sure how much I can say. Since I'm a contractor, I don't want to get my contracting company or the company they have me working at in trouble, as they are using this project to "beat" others to market (anybody up for a race). It's in the securities industry...but, that's a fairly large market, so I'm pretty safe saying that. The data is read-only, but will eventually not be (hm...I can feel big brother's bead hone in on my head). Dan
Post #60,274 by admin 10/30/02 3:58:02 PM Reply	Securities? I had better shaddup too then. :-P Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #60,297 by dshellman 10/30/02 5:30:42 PM Reply	Re: Securities? Yeah, it would be an interesting discussion about how to implement real-time data broadcasting on the web. There are existing products/technologies that do similar things to what we're both doing. However, it's a non-trivial application. It would be interesting to compare methods and implementations, especially since it seems we're doing very similar things (servlet front-ending a messaging server, etc.). It's too bad that businesses need to protect the details. Dan
Post #60,300 by admin 10/30/02 5:57:26 PM Reply	The existing solutions were not sufficient. And fairly trivial to reimplement, anyway. I'm not quite sure how they make money. :-P Took about a day to write the basics, then a week or so to refine it. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #60,304 by dshellman 10/30/02 6:07:26 PM Reply	Re: The existing solutions were not sufficient. Agreed. Though ours took a little longer to develop because of other requirements (tweaking to tune the performance, though, took a bit. Getting the best performance out of the back-end was a high priority given that it was supposed to provide real-time data. That wasn't completely trivial.). Dan
Post #60,306 by admin 10/30/02 6:11:55 PM Reply	Fortunately for us... ... we have a guy who'd done something like it before on the backend. He wrote the pubsub server. I wrote the javascript stuff. The remaining point of optimization is in the tunnel, but we haven't needed to do that yet. Optimize no sooner than necessary. ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #60,309 by dshellman 10/30/02 6:24:53 PM Reply	Re: Fortunately for us... Oh, so you didn't write the back-end as well. I didn't have to write the applet (though I helped a little). My job was to write the back-end. To me, that was the interesting thing (designing it for extensibility and performance at the same time). To be honest, my javascript/DOM skills aren't good enough to do it that way (and no one else here has them, either). I know it can be done, and know, generally, how it could be done, but that's about it. As for "optimize no sooner than necessary"....though I agree (since the statement is written such that you can't really disprove it), optimizing sooner, rather than later, isn't a bad thing, necessarily. The flip side...optimizing later on (on purpose) can put you into a position where you can't optimize without big changes (and that's one of the problems that we have....to integrate it with an existing, non-optimized, internal application). Dan
Post #60,313 by admin 10/30/02 6:40:42 PM Reply	Not talking about no optimization But, you optimize the design during the design phase, etc. The backend was the simplest part, actually, and it is ultra-optimized. The javascript was a lot of fun to do... I'd never done javascript before, so you could say we didn't have the skills in-house when we started either. ;-) The neat thing was that when I was done we had a javascript solution (frames, etc) that could also be piggy-backed by the applet. So, the applet does the communications, the javascript does the page object model and actual scripting. Best tool for each job. I've pushed my javascript up to 200 updates/sec during testing too, so it's fairly efficient... ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!