Java Applets are not slow per se, but the Java plugin is a pain to start. On a laptop a little busy, it can take somewhere around 10 seconds...
Plus, the first time I clicked on the links, it froze my browser. Granted, some other applets running might have been introducing some crappy threads in there, but welcome to the real world. If we use Java, we share the same JVM with any other Applets our end-user is viewing, and if one gets a dead-lock with the GUI thread, we're also dead.
Interactivity on the client side is necessary for smoothness of the display.
Deciding that I want to add a specific data set to my graph or that I want to see a histogram instead of a line plot has another dimension when you can actually do it instantly. The server-side roudtrip add an unnecessary perceived heavyweightness (should I say bloatiness) to the web app, even though architecturally, moving things to the client side is probably heavier.
I actually gave it a try... 'twas too long this idea was in my head, so I tried it....
My PC is approx. 1GHz.
320x20 (yes, 320x20 not 320x200) pixels takes approx 1 minute to be built through DHTML. (Using a table and a TD for every cell). Giving that 320x5 takes 4 seconds, it is not linear and we can deduce that a 320x200 matrix would be built in a couple of days.
See, I went to the link and it demonstrate exactly what we are trying to avoid. The live deom "2000 Presidential Election Results":
Every single time you click anything, the screen reloads and it takes 3-4 seconds to get the new graph. The user experience behind this kind of figures is really bad, as I don't keep in my mind an idea of a nice graph even though the graph was nicely drawn, beautifully anti-aliased. But barely usable.
Try out VML if you're not concerned by IE5 only limitations, and experience that with less download than one of your graphs (Same gore-bush example), you can have the same graph reacing instantly to your choices.
More offtopic is really a challenge after this one!
Anyways, I'll try to explain the problematic of the web-based applications: No deployment.
Cost of developping an HTML page running on Linux/Mac/Windows/IE/NS/Opera: 1 day Cost of developping a proprietary app running on all that (only showing the page in question, with let's say a little form): 2 weeks
That's a nice one but two problems over there: 1. That bounds us to IE since the "Save As" feature generates a very IE oriented output (even though it might work ugly on Netscape) 2. Then, why not using VML ? More flexible, lightweight, it's even a w3c standard
Yeah, except you don't have to pay for newer versions of RedHat.
The problem with you techies is that you think free software is free. Going every year through ALL computers and update them with the latest RedHat is probably more expensive than reinstalling new Windows systems every three years because MS support it for 3 years.
Well, I don't think you're right on this one. IE will be bundled with the OS, granted, but that doesn't mean you will not be able to install IE7 with WindowsXP. It just does mean it will be part of a service pack or another type of upgrade.
Maybe VML is good enough for now and when SVG will come along (read: wide native support or plugin deployed), we can move to it smoothly, since it is kind of a superset of VML.
I agree with the Linux part, but do you think Linux is any threat on the short term to Windows on the Desktop of enterprise networks ? I'm not so sure.
How is that interactive ? The whole point of the story is to ask for something interactive. If we have to generate images on the server side, number of libraries are out there to help us...
Well, very tempting, but how do you draw a pie chart with this solution? Granted you can position DIVs of one pixel anywhere in your page, the DOM control is not that fast that performance is going to become a major issue.
Plus, the first time I clicked on it, it froze my browser. Granted, some other applets running might have been introducing some crappy threads in there, but welcome to the real world. If we use Java, we share the same JVM with any other Applets our end-user is viewing, and if one dead-lock with the GUI thread, we're also dead.
Then VML would be the solution: Native support, no signing, no binary, lightweight XML-like language, JavaScript controlled through the DOM. Why in the world would we use anything else ?
It does exist and is achievable in a web browser. The question is more about "What's the state of the art today ?", or "What's the best alternative for our App ?"
The idea is that the more interactive the better. GIF/PNG generation on the server side is not that interactive, that's why we were looking at other possibilities.
It would be true with closed source, but with open-source software, end-users can put their resources toward getting the features they want, rather than toward paying Microsoft every few years.
You mean, they can check-out the file via CVS, make their enhancement, and then submit their changes to Linus ?
You know we're talking about secretaries, don't you ?
And the nice thing about OSS is that you don't really need to do mass upgrades to new major versions
Let's not take the RedHat vs. Microsoft example then. RedHat drops old versions a lot faster than MS.
You know, if MS doesn't do it, there is probably one reason: It does not make big bucks. And remember all the distros out there are made by companies that care about big bucks also.
I agree with you. The point of my original post is just to say that which DVD tech will be the standard is not relevant when it comes to choosing your DVD burner.
It was for Beta/VHS/V2000, but it is not with DVD-R/DVD+R.
Go with the one that suits your needs: cheaper, more compatible = DVD-R, Faster burning = DVD+R.
Slashdot Mirror
Java Applets are not slow per se, but the Java plugin is a pain to start. On a laptop a little busy, it can take somewhere around 10 seconds...
Plus, the first time I clicked on the links, it froze my browser. Granted, some other applets running might have been introducing some crappy threads in there, but welcome to the real world. If we use Java, we share the same JVM with any other Applets our end-user is viewing, and if one gets a dead-lock with the GUI thread, we're also dead.
Interactivity on the client side is necessary for smoothness of the display.
Deciding that I want to add a specific data set to my graph or that I want to see a histogram instead of a line plot has another dimension when you can actually do it instantly. The server-side roudtrip add an unnecessary perceived heavyweightness (should I say bloatiness) to the web app, even though architecturally, moving things to the client side is probably heavier.
I actually gave it a try... 'twas too long this idea was in my head, so I tried it....
My PC is approx. 1GHz.
320x20 (yes, 320x20 not 320x200) pixels takes approx 1 minute to be built through DHTML. (Using a table and a TD for every cell). Giving that 320x5 takes 4 seconds, it is not linear and we can deduce that a 320x200 matrix would be built in a couple of days.
Hmm, we'll need more than Hyperthreading.
I don't have the .ocx mentionned. Since when is Flash bundled in the default install of IE ?
See, I went to the link and it demonstrate exactly what we are trying to avoid. The live deom "2000 Presidential Election Results":
Every single time you click anything, the screen reloads and it takes 3-4 seconds to get the new graph. The user experience behind this kind of figures is really bad, as I don't keep in my mind an idea of a nice graph even though the graph was nicely drawn, beautifully anti-aliased. But barely usable.
Try out VML if you're not concerned by IE5 only limitations, and experience that with less download than one of your graphs (Same gore-bush example), you can have the same graph reacing instantly to your choices.
More offtopic is really a challenge after this one!
Anyways, I'll try to explain the problematic of the web-based applications: No deployment.
Cost of developping an HTML page running on Linux/Mac/Windows/IE/NS/Opera: 1 day
Cost of developping a proprietary app running on all that (only showing the page in question, with let's say a little form): 2 weeks
Don't forget the Cost of development includ QA.
See, native programs are not always the answer.
That's a nice one but two problems over there:
1. That bounds us to IE since the "Save As" feature generates a very IE oriented output (even though it might work ugly on Netscape)
2. Then, why not using VML ? More flexible, lightweight, it's even a w3c standard
Nice link. But it doesn't say: We don't make it for money. Please don't send us any money. We hate money.
Dude, you've got to realize that 99% of the people out there are working for money!!! That is just the drawback of Capitalism!!
Yeah, except you don't have to pay for newer versions of RedHat.
The problem with you techies is that you think free software is free. Going every year through ALL computers and update them with the latest RedHat is probably more expensive than reinstalling new Windows systems every three years because MS support it for 3 years.
Well, I don't think you're right on this one. IE will be bundled with the OS, granted, but that doesn't mean you will not be able to install IE7 with WindowsXP. It just does mean it will be part of a service pack or another type of upgrade.
Maybe VML is good enough for now and when SVG will come along (read: wide native support or plugin deployed), we can move to it smoothly, since it is kind of a superset of VML.
I agree with the Linux part, but do you think Linux is any threat on the short term to Windows on the Desktop of enterprise networks ? I'm not so sure.
How is that interactive ? The whole point of the story is to ask for something interactive. If we have to generate images on the server side, number of libraries are out there to help us...
Well, very tempting, but how do you draw a pie chart with this solution? Granted you can position DIVs of one pixel anywhere in your page, the DOM control is not that fast that performance is going to become a major issue.
Plus, the first time I clicked on it, it froze my browser. Granted, some other applets running might have been introducing some crappy threads in there, but welcome to the real world. If we use Java, we share the same JVM with any other Applets our end-user is viewing, and if one dead-lock with the GUI thread, we're also dead.
Java Applets are not slow per se, but the Java plugin is a pain to start. On a laptop a little busy, it can take somewhere around 10 seconds...
Keep in mind also that ALL WINDOWS USERS have IE at hand, even though thay might appear as Moz/Opera/Whatever in these statistics...
If you can control the browser to be IE5+
Then VML would be the solution: Native support, no signing, no binary, lightweight XML-like language, JavaScript controlled through the DOM. Why in the world would we use anything else ?
Do I need to mention that Lynx is not our target ? ;-)
Histograms works the way you describe, that is true, but other things needs to cooperate on the same graph as well...
Point taken: DHTML might be a reasonnable fallback.
It does exist and is achievable in a web browser. The question is more about "What's the state of the art today ?", or "What's the best alternative for our App ?"
The idea is that the more interactive the better. GIF/PNG generation on the server side is not that interactive, that's why we were looking at other possibilities.
It would be true with closed source, but with open-source software, end-users can put their resources toward getting the features they want, rather than toward paying Microsoft every few years.
You mean, they can check-out the file via CVS, make their enhancement, and then submit their changes to Linus ?
You know we're talking about secretaries, don't you ?
And the nice thing about OSS is that you don't really need to do mass upgrades to new major versions
Let's not take the RedHat vs. Microsoft example then. RedHat drops old versions a lot faster than MS.
You know, if MS doesn't do it, there is probably one reason: It does not make big bucks. And remember all the distros out there are made by companies that care about big bucks also.
Do I reply to AC?????
Blank media is going to be available for at least a couple of years which is more than the lifetime of these kind of drives anyways...
Granted I still have my first 4x CD burner, but I don't use it to burn anymore!
After two years the drive is so technically obsolete that you have to buy a new one anyways.
Even if you buy the DVD that is going too loose the market, what's the big deal? You still burn DVDs right?
It's not like all your DVD-/+R are going to be dead like your V2000 Tapes were right? You can still read them in most players out there....
I agree with you. The point of my original post is just to say that which DVD tech will be the standard is not relevant when it comes to choosing your DVD burner.
It was for Beta/VHS/V2000, but it is not with DVD-R/DVD+R.
Go with the one that suits your needs: cheaper, more compatible = DVD-R, Faster burning = DVD+R.
Of course, I meant V2000, not V200. Maybe I should start using hte preivew butoon...