News and commentary from the cross-platform scripting community.
|
||
|
Mail Starting 9/15/97 | |
I received messages from the Admin (sent to the whole list) explaining that the list was "un-moderateable", and that it served no purpose because "real developers" didn't subscribe to the list because it was just constant uninformed bickering. The people subscribed to the list, in his opinion, were not the people that the list intended to serve.
From: jroepcke@roepcke.com (Jim Roepcke);
Sent at 9/15/97; 5:15:05 PM;
Semper.Fi List..(Those are my words, not his)
The biggest problem (IMHO) was that every thread turned into a never-ending flame war with a lot of disrespect and redundancy.
Anyway, I don't really miss it.
Perhaps a private list with an "invitation-only" subscription would work better to fill the charter of that list. That could also include "small-time developers", if the charter included those people.
Scriptlets don't really match the power of applets. For one thing, as far as I can tell, their display capabilities are limited to HTML and images, and other formats that the browser already knows about. Java, on the other hand, lets me draw anything I want into its space. Thus, applets (and with HotJava and the future, pure-Java version of Netscape, content handlers) can act as dynamically-loaded, cross-platform plugins. I've seen, for example, an applet which lets you view DVI files on the Web (DVI being the output fomat of the TeX typesetter).
From: tmmoore@cmu.edu (Tim Moore);
Sent at 9/15/97; 5:25:28 PM;
Why I still like applets better than scriptletsFurthermore, and more importantly, Java applets are sent as bytecode, and not source code (as scripts are). There are already a number of compilers which compile non-Java languages (e.g., Rexx, Ada95, and some original languages like Pizza) into Java bytecode. So, theoretically at least, I don't need to care about what language an applet was written in, as long as it was compiled to Java bytecode (in the same way that I don't need to care about what language my Mac OS applications were written in, as long as they were compiled to Macintosh or Power Macintosh machine code). Scriptlets, on the other hand, are tied to their language's interpreter. There's a VBScript in this page? Oh, well I have a Mac, so I guess I can't see it until Microsoft decides to make an interpreter for my platform (at which point I would have to bother with downloading it, installing it...things the average computer user will just be confused by...why should I bother when I can go to some other page?) Same thing goes with any other interpreter that wasn't written in Java! Note that these are the same problems that plugins have. Personally, I see plugins being phased out over the next year, especially once Netscape goes to pure Java. Writing Java content handlers will probably be much simpler and easier to support.
Java isn't perfect, but I'm pretty convinced that it's the best we've got (for now, at leastt) and that its problems are immaturity problems, rather than conceptual problems (which I believe that COM/ActiveX "solutions" have).
Adobe has built a mini-HTTP server into the PostScript Level 3 code for printers. This lets the printer generate web-viewable status reports, configuration forms, etc, and also lets the printer "pull" documents over the web. This is a little different than having a scanner serve its scans, but then, printers and scanners are fundamentally different.
From: adamrice@crossroads.net (Adam Rice);
Sent at 9/15/97; 3:46:40 PM;
Fractional HTTP ServersWe seem to have had our contract developer blow up on us in the home stretch of a pretty complex project using Frontier. We're based in Boston, and I've been looking around scripting.com trying to find a referral to a Userland whiz, but w/no success.
From: acaper@hubnet.com (Adam Caper);
Sent at 9/15/97; 4:09:57 PM;
High & DryWe're really desperate (we have about 25 clients who've already signed up; the project was promised to us on 8/1...we're screwed!!)
http://www.hubnet.com
http://www.bostondine.com
http://www.partiesonline.com
I worked for several years as a software engineer at the HP division which does desktop flatbed scanners. This very device you're talking about has been bouncing around that lab for quite a while. Our idea was to have it mail messages back to the host station letting it know where on a file-sharing network the image was available, or even mail the image if it wasn't too big.
From: a former engineer at Hewlett-Packard
Re:Fractional Horsepower HTTP ServersYour point is well taken, that the standards are in place now that eliminate many of the questions we couldn't answer about how the best way was to get the image back to the user. Http solves the cross-platform question. Web pages are perfect since the images are low-resolution and small. Print resolution is not quite a good a fit, but you could age them and get rid of the oldest ones. The e-mail the user gets tells them the image will be available for 48 hours and then deleted.
I left that lab several years ago. It looks like the closest thing they've come to it so far is the same-old desktop flatbed, except with a button on the front that lets you initiate the scan from the scanner (the HP ScanJet 5P, I think), instead of the desktop software. An influence of Visioneer, no doubt.
I first heard the parable of the Electric Prime Mover and the Ubiquitous Little Electric Motor from Carver Mead in a lecture at the Jet Propulsion Laboratory around about 1976. The story, when I heard it, was obviously a couple of years old with Dr. Mead. Maybe he heard it from someone else, but I heard it first from him.
From: sam@conley.com (Sam Reynolds);
Sent at 9/15/97; 3:21:10 PM;
Steve Jobs comes up with great marketing slogans.The story, as told by Dr. Mead, observed that the earliest industrial installations depended on water or wind to drive the prime mover of each installation. In fact the use of water and wind established the notion of a prime mover, the one big thing that makes it all move. The water wheels, wind mills, and then steam engines drove a single line shaft which then drove many other shafts and so on down by direct mechanical linkage to the working parts of individual machines, like drill presses. When electric motors became practical, they replaced steam engines by driving the same line shafts originally driven by the steam engines. The line shafts and factories already existed; their operators were just applying a little cheaper prime mover to an existing capital investment.
Dr. Mead pointed out that there was a powerful economic reason for the origination of the prime mover system, that small water wheels, small wind mills, and to a lesser extent small steam engines aren't as efficient as big ones, all other technological things being equal. There are powerful economies of scale in water, wind, and steam. But not in electric motors.
Electric motors are cost effective at sizes small enough to put one in a drill, to keep the drill under the bench, and to let it sit idle when the worker at that bench doesn't need it. As the line shafts wore out and experience with electric motors grew, Dr. Mead observed, there was an inevitable progression to smaller motors powering individual machines and eventually to machines which could sit idle under a bench for most of the their working lives because it was cheaper to do that than to try to share the resource. Notice that prime mover based factories would share a prime mover, but that modern factories tend to replicate the motor and share the producer of electricity, because it's still more efficient to generate electricity at a large scale.
Dr. Mead compared the cost of producing and distributing mechanical power to the cost of producing and sharing computer memory. At that time, mid '70's, time sharing was the way computing was done. He observed that the cost of a core memory bit is very roughly proportional to the inverse cube of the number of bits. That's why large digital computers and time sharing were a good idea when core memory was the only practical memory technology. The bigger the main memory, the more cost effective was the computer. He pointed out that the cost of semicondonductor memory was approaching a linear function of the number of bits and that it was going to be cheaper to manufacture a lot of smaller computers and to let them sit idle when not needed.
Dr. Mead predicted that we would have computers on every desk and computers in coffee pots. He suggested that the the resistence of traditional computing institutions was due to a misunderstanding of the economic bases of their institutions and was simply futile, that their resistence couldn't possibly stand against the tide of the economic advantage of minicomputers and microcomputers. He was right. It's more that 20 years later, and we can all see that he was right.
Notice that Dr. Mead predicted that the emergence of mini and micro computers would not drive the progress and the nature of the use of semiconductor memory; rather, the nearly linear cost of semiconductor memory would drive out core memory, would drive the success of minicomputers and then microcomputers, and in fact would make the appearance of microprocessors in coffee pots and microwave ovens inevitable.
Dr. Mead wanted us at JPL to think seriously about designing a lot of little computers into spacecraft and ground data systems rather than depending on centralized computing resources. A lot of senior people didn't think much of the notion at the time, but he was right about that too. Within five years, the Deep Space Network had been completely redesigned and its computing was being moved from mainframes and minicomputers into thousands of Multibus single board computers. I have no idea how many microcomputers there are in modern spacecraft. I suspect that each instrument in each spacecraft has at least a couple of processors and that there are multiple data handling, command and control, and power management processors.
I hope that Steve Jobs attributed this story of the big motor that grew smaller and larger to Dr. Mead. I don't know whether he did or not. I just wanted to point out that the lesson to be drawn from the story is somewhat more subtle and profound than Mr. Jobs may have remembered or realized.
At Internet Showcase earlier this year a company founded by some ex-Novell people was demonstrating web servers for embedded devices. It sounds like what you're referring to for your scanner. Check it out: http://www.emware.com/
From: hardie@agentware.com (Hardie Tankersley);
Sent at 9/15/97; 11:46:36 AM;
Re:Fractional Horsepower HTTP ServersSomeday EVERYTHING will be on the web!
At Oklahoma State University http://osu.okstate.edu/, we've begun a wide-spread deployment of Macromedia's Shockwave Flash. I really pushed hard for this during the summer for because Flash's vector graphics are extremely friendly to my servers.
From: ultimate@fastpipe.com (Dennis Whiteman);
Sent at 9/15/97; 1:32:05 PM;
Re:ScriptletsBecause they require fewer connections to the server to load, they are much faster and offer comparable and advanced capabilities over JavaScript and Java. Because Netscape 3.0 runs under Windows 3.1, we have a tool that can offer multimedia support to a wider range of users than can Java. There isn't a Flash version for Unix, but then there isn't a reliable version of Java for Windows 3.1.
As an example of Flash's benefits, a web designer brought me a campus map done with GIFs and JavaScript for mouseovers that would have required the user to download 592k of graphics in 15 connections to my server. Doing the same map in Flash required about 30k and one connection to download. The user could download the flash plug-in (170k for the 32-bit Windows version) faster than downloading all the graphics required for the non-flash version of the Map, getting a better looking and feeling experience in the bargain.
We finally got agreement from OSU's Computing & Information Services to deploy Shockwave Flash on the lab computers that student's use and for the most part it's been a success, working reasonably well on everything from a 20mhz '040 (Centris 610) and a 486 DX50 to modern Power Mac and Pentium class computers. We finally have a home page that I like and it's being hosted on a 2-year-old Apple Workgroup Server 6150.
What I've discovered, however, is that we have people trying to run Netscape 3.0 on 386s with Flash and that's a disaster. Unfortunately, as much as I like to believe everyone has a computer built in the last three years, probably 25 percent of our users are using 386s and '030 Macs. And most Windows users have their video cards configured incorrectly or just don't have the capability to display correct colors, even in Netsape. We're looking at possible solutions, but the fact is some of these people are going to get left behind as MSIE/Netscape 4/5/6 roll out.
I hate having to support every browser down to and including the original Mosaic and computers built in 1990. But that's the price you pay for supporting a universally accessible medium.
How do you tell MSIE which language the script is written in? Also, what does a language implementor need to know in order to get their scripting language to work with this system?
From: rjohnson@Eng.Sun.COM (Raymond Johnson);
Sent at 9/15/97; 11:25:00 AM;
Re:ScriptletsIt's this last point that is usually the sticking point with Microsoft. They claim to be open - but then you must reimplement everything in OLE or something in order to be part of this "open" system. It would be nice to hear that this isn't the same old news.
Ray Johnson
Sun Labs