this is almost as bad as the "embed windows in everything" clarion on
m$. i assume your definition of "web server" is something much more
than today's "dumb rpc server for documents plus creative use of the
fork() system call". in fact, i'm sure it's much more than tomorrow's
"smart, extensible rpc server for documents (active and passive), plus
creative use of protocols, threads, fork(), and the kitchen sink".
heck, let's even throw in some key services like security and real
authentication and transactions and...wait a second!
and as far as the iiop bigots go, your handy-dandy html form can be
found at schlage.com/medeco/combolock/v13-socket-bug.asp, if you can
get the server not to wig out or your creaking twenty-five megabyte
web client not to crash while you are accessing it since your netscape
xml v2 seems to only occasionally agree with the servers xml v2.01m$.
> The hardware key to web servers everywhere is tougher: it's a
> price/communications barrier. The $1 munchkin with self-configuration is a
> solution. ad-hoc installation is *critical* and can't be done well with IP
> technology of today.
my first-pass question wrt this munchkin postulate is where does the
power come from? i know, i know, asynchronous technologies use less
power for this and that reason, but have you really looked at any
numbers when it comes to powering up anything that has to transmit and
receive bits for long periods of time? (or even short periods - like a
car, the "starting up" bit is the most expensive in power usage)
have you seen how dismal battery technologies are, and seemingly will
continue to be for the near to medium future?
are we planning on piping power in on the carrier somehow?
> Also, everyone up on emWeb, from aragnat systems? Happen to be pioneers on
> feature negotiation, too.
>
> Rohit
>
> PS .Below is from a quick WSJ profile.
...deleted for space...
joe