...the exact opposite of an inflatable space station, is a skin tight space-suit! If we could develop that technology, space walks could become as easy as diving! (If not a smidge easier.)
One question, were you seeing pages scroll back to the top after every page refresh?
Unfortunately, I don't remember if they do and I can't check (for obvious reasons). Personally, that's not a hack I ever liked much. Especially since you have to set the location at the end of the page. This can cause the page to "jump" a little after reloading, making the flash that much harder to eliminate.
I'm looking forward to you guys using more DHTML.:-)
Did you read my response? A Big Gemini capsule could easily meet the requirements. Especially on the reentry part. All that's needed is a classic epoxy/silicon heat shield, then the parawing for landing. On the ground the heat shield would be peeled off and replaced, the parawing repacked, and the capsule would be ready for relaunch.
We discussed a possible solution just a few days ago. The only thing I didn't mention is that the Falcon V would be a good alternative choice for launch vehicle. Especially given how much Boeings prices tend to fluctuate upward for newcomers.
It's kind of cool to see this idea come to fruition. I'm sure that every child has gone through one of those inflatable castles and wondered what it would be like to have an inflatable house. I myself have often wondered if houses on other planets could be constructed in a manner similar to the late Xanadu. Just inflate the basic structure with just high enough PSI to make it rigid, then spray foam all over it. Allow the structure to cure, and you've got yourself air-tight, super-strong walls that can be repaired from pretty much any damage just by spraying more foam!
Having a degree and being at the top of the field are not the same thing.
I perfectly agree with that. However, you can't expect an expert in a field to drop everything and go to work for the patent office. So you're going to have to make due with someone trained in the field, but not necessarily an expert in said field.
That's why public review and re-evaluation requests are so important. If a patent does affect experts in a field in a negative way then they can take the time to challenge it.
The long refresh delay you're seeing is in no small part caused by the demonstration server being entirely overloaded due to/.'ing.
Actually, I got to it before it was Slashdotted. The page refreshes were fast enough, but not so fast as to be unnoticeable. Even if you manage to make the "flash" the user sees invisible, they'll still notice when their screen scrolls back up to the top. I used to save the scroll position before refresh on an advanced calendar control that I had written back in ~'00. If I were doing the same thing today, I'd definitely write the control in DHTML. (CSS+Javascript to be exact.)
With regard to making such extensive use of DHTML as to minimize the load on the server, bear in mind that server load is only one factor
It's not really the server load that's the factor. (Although it's always nice to get a better bang for your buck.) It's really about bandwidth and perceived performance. Anything above 10K in size is going to produce a noticeable delay in refresh. This may have nothing to do with the server, and everything with the client. Even with high bandwidth connections, the latency introduced into the system can frustrate the user. Most users are used to it at this point, but it doesn't need to be that way.
In addition, DHTML also improves perceived performance. Even if you still have a ~3 second turnaround before the tree control opens up, the user is always going to say that the DHTML one is faster than the page refresh one. The reason is quite simple: The human brain is very smart. It knows when even the slightest thing has changed. Thus the same factors that led to the development of Double Buffering come into play in web applications.
In most cases a more powerful server is far less expensive than having developers write unmaintainable code.
I agree with the more powerful hardware point, but I don't think that CSS and JavaScript have to be unmaintainable. Over the years I've had a very powerful love/hate relationship with JavaScript. But with modern browsers the scale is beginning to tip toward love.
You see, the JavaScript I write these days is fully OO, with every object separated into its own file. I'm always careful about the scope of my variables, and I use explicit cast functions when I'm uncertain about the type. The result is highly maintainable JavaScript that almost feels like writing Java code. The only problems this has led to is that I keep trying to use "int" instead of "var", and I always forget NOT to use "var" in front of function variables. Other than that, a control can be as simple as instantiating a JavaScript object.:-)
I'm all for making as much use of DHTML as possible, but it must be done behind the scenes of a more practical API.
I'm all for what you guys are doing. Well written server APIs are always the way to go. But that doesn't mean that the server APIs can't push DHTML to the client. Especially when all the DHTML is packed into proper libraries.
But I will say DHTML Lemmings is quite extraordinary, that is one of the most impressive uses of DHTML I have seen.
Isn't it though? Now if Microsoft would fix the damn "position: fixed" attribute, we'd be well on our way to producing entire Desktops based around DHTML interfaces!:-)
* patent examiners are woefully undertrained; they should be among the best in their field, but the low wage of examiners means that those who actually know what they're doing find other jobs
Are we talking about the same country? In the US, the patent examiners are required to have an applicable degree before their considered for the job.
As for their wages, the upper range is well over $100,000. Read the article I posted as info for the first reply.
1. It's not my code. 2. Look at the second link I posted. There's a link to download the source, sans the graphics and sound. 3. Pages communicate via a combination of cookies and parsing the URL parameters. 4. To snag the graphics from the site, download the source code and try something like this:
A perfect example of how the system should work. The patent office doesn't need a reform, it needs to simply do a better job of following its own rules. Organizations like PubPat are a good thing, because they add another layer of checking (i.e. public responsibility) to the patent process.
It may surprise many to know that patent officers are often promoted on how many patents they reject, not how many they approve. Thus it is in their interest to reject any applications with even the slightest possibility of being invalid. Yet it seems that ridiculous patents make it through anyway. How does this happen?
The answer lies in the patent lawyers who draw up the papers. What they'll do, is that they'll draw up revision after revision of the idea until the patent office is confused enough to grant it. (Or perhaps they lucked upon a new patent officer.) That's why most of these patents seem so vague. The applicants are making sure that there's no way someone who doesn't have a very thorough education in the field of the patent could understand that the idea is unpatentable. Thus the idea passes through the process and must be challenged in court or via reexamination later.
All you need to do is scale it a bit. What if the tree had 500 items at the top level? Then the savings would be extreme.
In the real world, however, the savings would be immediate even with the exact example I gave. The reason is that most pages contain sidebars, titles, helpful text, and other controls. All of that data adds up, and can often be 10K or larger. In the DHTML web application I'm working on, pages are regularly 70K+. Yet since only minor parts of the page change, the savings are significant.
While DHTML Lemmings is a great example of the powers of DHTML, it is a poor example to contrast against a web application since it never needs to read/write from a db, nor communicate with a server.
While this is true, there are (unfortunately) very few public applications that make good use of DHTML. The only one that comes to mind is the example of GMail. DHTML greatly improves the user experience in that case and decreases their server load.
I don't think this is possible, because the ECHO framework is heavily dependent on server-side state information [...] but without DHTML (since there's no need for or advantage to it).
Believe it or not, DHTML can still improve this situation. Let's take the tree control as an example. Right now the current state of the tree is pushed to the client. When the client modifies the tree, it gets refreshed. But why?
Let's say we have a tree that looks like this:
+ ABC + 123 + This is a test
Using DHTML, the server only needs to push three rows to the client. Now let's say the client has a hidden iframe with the following HTML:
So what happens with DHTML if I click on "ABC"? Simple! The Javascript sets "command" to "expand" and "field" to "tree_abc" (or whatever the element is called), then submits the form. The server reads in the request and passes back Javascript that modifies the innerHTML of the ABC element along with the same input fields as above.
once the innerHTML is modified, the tree now looks like this:
-ABC
* Ardvark
+ Animal
* Aligator
* Algae + 123 + This is a test
The end result is that the server knows that the tree was expanded, and only the data absolutely necessary was transmitted. The savings are anywhere from tens to hundreds of K per action, and the user notices that the application is much faster. The screen doesn't even flash when he clicks!
So yes, DHTML could greatly improve this framework.
More client side stuff == more memory load on the client, often disproportionate. [...] in the order of 30 MB for the application. There was only a few hundred K of javascript.
True. But I'm doing DHTML on a 256MB machine. It's plenty fast enough. You always have to pay attention to whether DHTML will help your application or hurt it. If you need a very high level of interaction, and/or find yourself having to pump large amounts of uneeded data to the client (e.g. a combo box with ~10,000 rows), then DHTML makes sense. Otherwise, plain old HTML may actually be faster and more client friendly.
1) Netscape 4 support. It sucks, and it's got a whole raft of bugs with dynamic frames and UTF-8.
Time to give that up. I don't know about anyone else, but none of the sites I run support Netscape 4 anymore. It's not only 10 years old, but it's been replaced by several newer versions of Netscape, all of which function just fine with DHTML.
Anyone who's still using Netscape 4 either has a VERY old computer, or needs their head checked.
Less need for a server != you must give up the server. In the DHTML I'm working on, I'm able to send individual field to the database without refreshing the page or doing a form submit. You see, there's a hidden iFrame that's designed to communicate one field at a time. If an error occurs upon submit, the returned version of the communications page embeds an alert popup to tell the user what the error was. After the user clicks on "ok". the field is reverted back to its previous form.
Other implementations could mark the field in red and force focus until the user fixes it or hits escape. You could even embed some text in red all by changing the document via DHTML. The total amount of data that travels between the client and server? Less than a kilobyte!
Less data == less bandwidth & processing Less bandwith & processing == more responsiveness & high load abilities More responsiveness & high load abilities == happier clients
Is it just me or do all the pages refresh every time you do anything? I've been doing some internal applications in DHTML lately and have learned the amount of stuff DHTML can do (even if you avoid some of the more browser specific stuff). There's little reason to refresh the page for every event.
If you want to see what DHTML can *really* do. Look no further than DHTML Lemmings. It's an entirely self-contained application that can run on your local hard drive without the support of a server. The current level is cookied so that you don't have to start over when you close your browser. All parameter handling is done by parsing the URL with Javascript. In other words, there is ZERO need for a server.
Less need for a server translates to less strain on the server. Less strain on the server means that your applications will perform faster for both the client and your company.
I'm going for the patent on combining a secret spy computer with a schoolbook. It would have built in wireless, video phone capabilities, and a complete library of all spy data (especially info on M.A.D.D.)
After that, I'm patenting extendo-legs with springs, hat helicopters, and exploding paper. Oh, and I'm trademarking the line, "I'm always on duty!(TM)"
But they sure as hell as better work on the *deployment* of parawings then.
Well, if a human was onboard he could have yanked the manual release. Remember, the drough (sp?) chute failed to deploy as well. Safety systems for humans are supposed to predict those sorts of problems and allow them to correct using one or more failsafe methods.
I imagine there are *lots* of possible failure modes of re-entry.
I'm sure there are. But there are also quite a few advantages of a capsule in failure situations. For one, if the parachute fails it will be traveling at terminal velocity (~100 mph). The return method can be planned that the capsule will aim for the coast and steer itself toward land with the parawing. In case of a deployment failure, it would land in the water as opposed to dry land. It would still be a pretty hard landing, but the crew would have a good chance of survival.
Another thing that could be planned for is the heat shield. The Apollo craft actually used a heat shield that was *way* overdesigned. This made reentry one of the least of their concerns. In comparison, the space shuttle is designed for a precise reentry profile, and has fairly fragile shielding for the sections that have to withstand the plasma. I don't know about you, but I feel a bit safer with thick honeycombs of epoxy-like silicon rather than something with the strength of bathroom tiles.
After all, as has been said, it *is* rocket science.
Minor correction. I just checked and it looks like Rotorooter finally wrote their own. I highly recommend those guys if you need a plumber! Rescue Rooter may look tempting, but Rotorooter was ALWAYS on time for our customers!
The big question here is how you can possibly build customer loyalty if you outsource the business unit which is in charge of customer relationships. This doesn't sound like a wise idea to me.
How much do you talk with Google? Do you call up Amazon much? If you get it right, outsourcing customer relationships is not a big problem.
I used to work for MyHomeKey.com, and customer relations was a BIG part of our business. (I think we outsourced it to a company in Texas.) Generally speaking, we had top notch phone and email support. When people used it, that is. For the most part they could check statuses online and figure out what was going on. If something changed in the date we got a service tech out there, our support would call the customer.
The only reason why things didn't work out is that the businesses we worked with (everyone from Home Service Store to Sears) couldn't handle more than 300 service orders a day! The ONLY company who was always on time and always handled their orders was Rotorooter. (If anyone remembers when Rotorooter had online ordering, that was my technology!) Everyone else kind of threw up their hands and said, "it's just too much". *sigh*
The parent isn't flamebait. The grandparent is flamebait. Why mod the responses?
My own thoughts on the debate are as follows:
- Bush will answer questions pointing to what he believes he's done well, and will generally skirt around some issues to avoid fibbing or outright lying. Expect that some legalese (i.e. responding to the exact words vs. their intended meaning) may be used to skirt around some questions.
- Kerry will answer every question by promising the moon, even if his promises are contradictory.
As for this whole dual-party setup of the debates, consider this: The panel did allow Ross Perot into the debates, and it was enough to prevent Bush Sr. from winning the election.
Maybe someone made a mistake, but according to webelements, Ni63 has a half-life of 100 years. With that half-life, the material would be considered moderately radioactive.
Slashdot Mirror
...the exact opposite of an inflatable space station, is a skin tight space-suit! If we could develop that technology, space walks could become as easy as diving! (If not a smidge easier.)
One question, were you seeing pages scroll back to the top after every page refresh?
:-)
Unfortunately, I don't remember if they do and I can't check (for obvious reasons). Personally, that's not a hack I ever liked much. Especially since you have to set the location at the end of the page. This can cause the page to "jump" a little after reloading, making the flash that much harder to eliminate.
I'm looking forward to you guys using more DHTML.
Did you read my response? A Big Gemini capsule could easily meet the requirements. Especially on the reentry part. All that's needed is a classic epoxy/silicon heat shield, then the parawing for landing. On the ground the heat shield would be peeled off and replaced, the parawing repacked, and the capsule would be ready for relaunch.
We discussed a possible solution just a few days ago. The only thing I didn't mention is that the Falcon V would be a good alternative choice for launch vehicle. Especially given how much Boeings prices tend to fluctuate upward for newcomers.
It's kind of cool to see this idea come to fruition. I'm sure that every child has gone through one of those inflatable castles and wondered what it would be like to have an inflatable house. I myself have often wondered if houses on other planets could be constructed in a manner similar to the late Xanadu. Just inflate the basic structure with just high enough PSI to make it rigid, then spray foam all over it. Allow the structure to cure, and you've got yourself air-tight, super-strong walls that can be repaired from pretty much any damage just by spraying more foam!
Something to think about, anyway.
Having a degree and being at the top of the field are not the same thing.
I perfectly agree with that. However, you can't expect an expert in a field to drop everything and go to work for the patent office. So you're going to have to make due with someone trained in the field, but not necessarily an expert in said field.
That's why public review and re-evaluation requests are so important. If a patent does affect experts in a field in a negative way then they can take the time to challenge it.
Hi Tod! Thanks for replying!
/.'ing.
:-)
:-)
The long refresh delay you're seeing is in no small part caused by the demonstration server being entirely overloaded due to
Actually, I got to it before it was Slashdotted. The page refreshes were fast enough, but not so fast as to be unnoticeable. Even if you manage to make the "flash" the user sees invisible, they'll still notice when their screen scrolls back up to the top. I used to save the scroll position before refresh on an advanced calendar control that I had written back in ~'00. If I were doing the same thing today, I'd definitely write the control in DHTML. (CSS+Javascript to be exact.)
With regard to making such extensive use of DHTML as to minimize the load on the server, bear in mind that server load is only one factor
It's not really the server load that's the factor. (Although it's always nice to get a better bang for your buck.) It's really about bandwidth and perceived performance. Anything above 10K in size is going to produce a noticeable delay in refresh. This may have nothing to do with the server, and everything with the client. Even with high bandwidth connections, the latency introduced into the system can frustrate the user. Most users are used to it at this point, but it doesn't need to be that way.
In addition, DHTML also improves perceived performance. Even if you still have a ~3 second turnaround before the tree control opens up, the user is always going to say that the DHTML one is faster than the page refresh one. The reason is quite simple: The human brain is very smart. It knows when even the slightest thing has changed. Thus the same factors that led to the development of Double Buffering come into play in web applications.
In most cases a more powerful server is far less expensive than having developers write unmaintainable code.
I agree with the more powerful hardware point, but I don't think that CSS and JavaScript have to be unmaintainable. Over the years I've had a very powerful love/hate relationship with JavaScript. But with modern browsers the scale is beginning to tip toward love.
You see, the JavaScript I write these days is fully OO, with every object separated into its own file. I'm always careful about the scope of my variables, and I use explicit cast functions when I'm uncertain about the type. The result is highly maintainable JavaScript that almost feels like writing Java code. The only problems this has led to is that I keep trying to use "int" instead of "var", and I always forget NOT to use "var" in front of function variables. Other than that, a control can be as simple as instantiating a JavaScript object.
I'm all for making as much use of DHTML as possible, but it must be done behind the scenes of a more practical API.
I'm all for what you guys are doing. Well written server APIs are always the way to go. But that doesn't mean that the server APIs can't push DHTML to the client. Especially when all the DHTML is packed into proper libraries.
But I will say DHTML Lemmings is quite extraordinary, that is one of the most impressive uses of DHTML I have seen.
Isn't it though? Now if Microsoft would fix the damn "position: fixed" attribute, we'd be well on our way to producing entire Desktops based around DHTML interfaces!
* patent examiners are woefully undertrained; they should be among the best in their field, but the low wage of examiners means that those who actually know what they're doing find other jobs
Are we talking about the same country? In the US, the patent examiners are required to have an applicable degree before their considered for the job.
As for their wages, the upper range is well over $100,000. Read the article I posted as info for the first reply.
Of course. I think you'll find this article most enlightening. My favorite quote is:
SPEs want these new employees to gain experience rejecting patent applications, and there is considerable pressure on these new hires to do so.
1. It's not my code.
2. Look at the second link I posted. There's a link to download the source, sans the graphics and sound.
3. Pages communicate via a combination of cookies and parsing the URL parameters.
4. To snag the graphics from the site, download the source code and try something like this:
find . -exec grep level_image {} \; > temp.txt
cat temp.txt | grep gfx | cut -d \' -f 6 > levels/gfx/gfx.txt
cd levels/gfx
wget -i gfx.txt -B [http://whateverthebasurlwas]/levels/gfx/ -nd
A perfect example of how the system should work. The patent office doesn't need a reform, it needs to simply do a better job of following its own rules. Organizations like PubPat are a good thing, because they add another layer of checking (i.e. public responsibility) to the patent process.
It may surprise many to know that patent officers are often promoted on how many patents they reject, not how many they approve. Thus it is in their interest to reject any applications with even the slightest possibility of being invalid. Yet it seems that ridiculous patents make it through anyway. How does this happen?
The answer lies in the patent lawyers who draw up the papers. What they'll do, is that they'll draw up revision after revision of the idea until the patent office is confused enough to grant it. (Or perhaps they lucked upon a new patent officer.) That's why most of these patents seem so vague. The applicants are making sure that there's no way someone who doesn't have a very thorough education in the field of the patent could understand that the idea is unpatentable. Thus the idea passes through the process and must be challenged in court or via reexamination later.
All you need to do is scale it a bit. What if the tree had 500 items at the top level? Then the savings would be extreme.
In the real world, however, the savings would be immediate even with the exact example I gave. The reason is that most pages contain sidebars, titles, helpful text, and other controls. All of that data adds up, and can often be 10K or larger. In the DHTML web application I'm working on, pages are regularly 70K+. Yet since only minor parts of the page change, the savings are significant.
While DHTML Lemmings is a great example of the powers of DHTML, it is a poor example to contrast against a web application since it never needs to read/write from a db, nor communicate with a server.
:-)
While this is true, there are (unfortunately) very few public applications that make good use of DHTML. The only one that comes to mind is the example of GMail. DHTML greatly improves the user experience in that case and decreases their server load.
Also, I gave a real-world example of DHTML here.
That DOMAPI you mentioned looks very interesting. I'll have to check it out sometime.
Believe it or not, DHTML can still improve this situation. Let's take the tree control as an example. Right now the current state of the tree is pushed to the client. When the client modifies the tree, it gets refreshed. But why?
Let's say we have a tree that looks like this:Using DHTML, the server only needs to push three rows to the client. Now let's say the client has a hidden iframe with the following HTML:So what happens with DHTML if I click on "ABC"? Simple! The Javascript sets "command" to "expand" and "field" to "tree_abc" (or whatever the element is called), then submits the form. The server reads in the request and passes back Javascript that modifies the innerHTML of the ABC element along with the same input fields as above.
once the innerHTML is modified, the tree now looks like this:The end result is that the server knows that the tree was expanded, and only the data absolutely necessary was transmitted. The savings are anywhere from tens to hundreds of K per action, and the user notices that the application is much faster. The screen doesn't even flash when he clicks!
So yes, DHTML could greatly improve this framework.
More client side stuff == more memory load on the client, often disproportionate. [...] in the order of 30 MB for the application. There was only a few hundred K of javascript.
True. But I'm doing DHTML on a 256MB machine. It's plenty fast enough. You always have to pay attention to whether DHTML will help your application or hurt it. If you need a very high level of interaction, and/or find yourself having to pump large amounts of uneeded data to the client (e.g. a combo box with ~10,000 rows), then DHTML makes sense. Otherwise, plain old HTML may actually be faster and more client friendly.
1) Netscape 4 support. It sucks, and it's got a whole raft of bugs with dynamic frames and UTF-8.
Time to give that up. I don't know about anyone else, but none of the sites I run support Netscape 4 anymore. It's not only 10 years old, but it's been replaced by several newer versions of Netscape, all of which function just fine with DHTML.
Anyone who's still using Netscape 4 either has a VERY old computer, or needs their head checked.
Less need for a server != you must give up the server. In the DHTML I'm working on, I'm able to send individual field to the database without refreshing the page or doing a form submit. You see, there's a hidden iFrame that's designed to communicate one field at a time. If an error occurs upon submit, the returned version of the communications page embeds an alert popup to tell the user what the error was. After the user clicks on "ok". the field is reverted back to its previous form.
Other implementations could mark the field in red and force focus until the user fixes it or hits escape. You could even embed some text in red all by changing the document via DHTML. The total amount of data that travels between the client and server? Less than a kilobyte!
Less data == less bandwidth & processing
Less bandwith & processing == more responsiveness & high load abilities
More responsiveness & high load abilities == happier clients
Is it just me or do all the pages refresh every time you do anything? I've been doing some internal applications in DHTML lately and have learned the amount of stuff DHTML can do (even if you avoid some of the more browser specific stuff). There's little reason to refresh the page for every event.
If you want to see what DHTML can *really* do. Look no further than DHTML Lemmings. It's an entirely self-contained application that can run on your local hard drive without the support of a server. The current level is cookied so that you don't have to start over when you close your browser. All parameter handling is done by parsing the URL with Javascript. In other words, there is ZERO need for a server.
Less need for a server translates to less strain on the server. Less strain on the server means that your applications will perform faster for both the client and your company.
It would slow down to terminal velocity (~100 mph). Not sure if the pilot could eject, though.
I'm going for the patent on combining a secret spy computer with a schoolbook. It would have built in wireless, video phone capabilities, and a complete library of all spy data (especially info on M.A.D.D.)
After that, I'm patenting extendo-legs with springs, hat helicopters, and exploding paper. Oh, and I'm trademarking the line, "I'm always on duty!(TM)"
But they sure as hell as better work on the *deployment* of parawings then.
;-)
Well, if a human was onboard he could have yanked the manual release. Remember, the drough (sp?) chute failed to deploy as well. Safety systems for humans are supposed to predict those sorts of problems and allow them to correct using one or more failsafe methods.
I imagine there are *lots* of possible failure modes of re-entry.
I'm sure there are. But there are also quite a few advantages of a capsule in failure situations. For one, if the parachute fails it will be traveling at terminal velocity (~100 mph). The return method can be planned that the capsule will aim for the coast and steer itself toward land with the parawing. In case of a deployment failure, it would land in the water as opposed to dry land. It would still be a pretty hard landing, but the crew would have a good chance of survival.
Another thing that could be planned for is the heat shield. The Apollo craft actually used a heat shield that was *way* overdesigned. This made reentry one of the least of their concerns. In comparison, the space shuttle is designed for a precise reentry profile, and has fairly fragile shielding for the sections that have to withstand the plasma. I don't know about you, but I feel a bit safer with thick honeycombs of epoxy-like silicon rather than something with the strength of bathroom tiles.
After all, as has been said, it *is* rocket science.
Rocket science is highly overrated.
Minor correction. I just checked and it looks like Rotorooter finally wrote their own. I highly recommend those guys if you need a plumber! Rescue Rooter may look tempting, but Rotorooter was ALWAYS on time for our customers!
The big question here is how you can possibly build customer loyalty if you outsource the business unit which is in charge of customer relationships. This doesn't sound like a wise idea to me.
How much do you talk with Google? Do you call up Amazon much? If you get it right, outsourcing customer relationships is not a big problem.
I used to work for MyHomeKey.com, and customer relations was a BIG part of our business. (I think we outsourced it to a company in Texas.) Generally speaking, we had top notch phone and email support. When people used it, that is. For the most part they could check statuses online and figure out what was going on. If something changed in the date we got a service tech out there, our support would call the customer.
The only reason why things didn't work out is that the businesses we worked with (everyone from Home Service Store to Sears) couldn't handle more than 300 service orders a day! The ONLY company who was always on time and always handled their orders was Rotorooter. (If anyone remembers when Rotorooter had online ordering, that was my technology!) Everyone else kind of threw up their hands and said, "it's just too much". *sigh*
I'll have you know that it was a big damn bubble!
The parent isn't flamebait. The grandparent is flamebait. Why mod the responses?
My own thoughts on the debate are as follows:
- Bush will answer questions pointing to what he believes he's done well, and will generally skirt around some issues to avoid fibbing or outright lying. Expect that some legalese (i.e. responding to the exact words vs. their intended meaning) may be used to skirt around some questions.
- Kerry will answer every question by promising the moon, even if his promises are contradictory.
As for this whole dual-party setup of the debates, consider this: The panel did allow Ross Perot into the debates, and it was enough to prevent Bush Sr. from winning the election.
Maybe someone made a mistake, but according to webelements, Ni63 has a half-life of 100 years. With that half-life, the material would be considered moderately radioactive.