I agree with your notion that supporting modem access is going to be
something of an ongoing concern. However, the most popular current scheme
is to setup SLIP/PPP and use everything as normal. The only big advantage
of this over a dedicated transfer protocol (like Kermit) is that SLIP
presumably takes care of multiplexing multiple connections. In practice,
once you start a single BIG transfer, since no-one takes care to implement
load-throttling, you might as well be directly connected through one
session, because everything else comes to a halt.
I have seen some incredibly cool asynchronous protocols implemented over
serial lines that allow you to continue working while a transfer is
in progress. SoftArc's First Class and certain versions of Blast immediately
come to mind. And through gateways, you can basically perform what you
would over SLIP.
The issue is not VC versus DG's. TCP is just one implementation of
VC's over a datagram layer. Those who don't like TCP's default overhead
for certain media and applications argue for doing a simpler DG-based
protocol. I personally think it's all irrelevant since the debate is
not about functionality but about performance. And since there
are a lot more areas where you can squeeze performance, the VC/DG
issue is something of an academic exercise best left to the readers (;-)
I say we go ahead and dispense with the VC<->DG debate. I prefer the RPC
vs. Messaging one. Should libwww just switch to RPC and do away with
this HTTP protocol business. Anyone? >;-)
Cheers,
R.
-- Ramin Firoozye' rp&A Inc. - San Francisco, California Internet: rpa@netcom.COM - CIS: 70751,252--