• To: veillard@r..., Ralph Ferris <ralphf@v...>
• Subject: Re: SV: Tim Bray on "Which Technologies Matter?"
• From: James Clark <jjc@j...>
• Date: Wed, 20 Mar 2002 09:57:52 +0700
• Cc: xml-dev@l...
• In-reply-to: <20020319160040.U27396@r...>
• References: <20020319160040.U27396@r...>

>> For the record, the major problem found with SP had nothing to do with
>> SGML processing overhead. Rather, when James Clark wrote SP, he wrote
>> his own (non-Winsock) socket classes. Re-working James' code to work
>> with proxy servers did not prove feasible. This of course would have
>> been a serious defect in a commercial product, and was a significant
>> factor in the decision to terminate the project.
>
>   Surprizing, seems strange that the behaviour of the bottom of the stack
> can't be changed while preserving its semantic to the upper layer...

There seems to be some confusion here.

Out of the box, SP provides two ways to access URLs. The default is a 
home-grown, bare-bones but system independent HTTP 1.0 implementation, 
written on top of sockets (i.e. Winsock on Windows).  This doesn't support 
proxy servers. The alternative (enabled by defining SP_WININET at compile 
time) is a Win32 specific implementation; this uses the standard Win32 
client-side URL access API (known as WinInet); this is what Internet 
Explorer uses and it certainly supports proxy servers.  It's easy to make 
SP use any other URL access API just by implementing the StorageManager 
interface.

James

• References:
  • Re: SV: Tim Bray on "Which Technologies Matter?"
    • From: Daniel Veillard <veillard@r...>

• Prev by Date: RE: XmlTextReader for Java?
• Next by Date: Re: Training
• Previous by thread: Re: SV: Tim Bray on "Which Technologies Matter?"
• Next by thread: RE: SV: Tim Bray on "Which Technologies Matter?"
• Index(es):
  • Date
  • Thread