Scott Raney wrote:
>
> On Mon, 11 Sep 2000, Dave Cragg wrote:
>
> > I've been playing with the sockets features in order to try and
> > implement some client side http. I've been doing this because
> > Metacard's built-in http support won't work with some URLs (something
> > to do with the way aliasing is set up on the server, I think).
>
> Please try 2.3.2, which is a lot better about these things. It has
> just been released to beta test and now available for Linux, MacOS,
> and Win32 in the directory ftp://ftp.metacard.com/MetaCard/2.3.2/
>
> > The script below is a crude first attempt at this. It simply loads
> > the data from the specified URL. (I've removed some stuff that was
> > specific to my situation.) So far, it seems to work, even with
> > previously unreachable URLs. Ideally, I'd like to be able to emulate
> > the built-in http features of Metacard, but using sockets. (I've also
> > had a go at the POST method, and it seems to work, but I need to make
> > a more general solution than what I've done so far.)
>
> We're actually working on the same thing, as the plan all along was to
> replace the built-in HTTP routines with an script library that uses
> sockets to do HTTP, FTP, and other protocols. We welcome your
> participation in the design, implementation, and testing of this new
> library.
>
> 2.3.2 already has one new feature that will make implementing such a
> library much easier: a "wait for messages" command which allows event
> dispatching within a handler. This is useful for building synchronous
> function calls that still require some event dispatching (e.g., one
> that does the equivalent of "get url http://somehost/somefile").
Thank's for doing it : probably, no more php or perl sockets listeners needed
!!!
> > The scripts may be useful to anyone else wanting to do the same
> > thing. More importantly, I'd appreciate any feedback from the sockets
> > gurus about whether I'm going in the right direction.
> >
> > Two questions foremost on my mind:
> >
> > In order to show progress of the download (progress bar or whatever),
> > is it necessary to do reads in short steps (as in the script below)
> > or is there another way?
>
> The best way to do it is to do a simple "read from socket <s> with
> message <m>" and handle the assembly and processing of the data in the
> message handler. This does the chunking automatically for you in
> whatever size chunks the OS is dealing in and so is the most efficient
> method.
>
> > How to handle http proxies? Is this just a question of opening the
> > socket to the proxy and carrying on as before, or is it, as I fear,
> > more torturous?
>
> There are (at least) two types of proxies: those that you know the
> address of and those where the proxy is actually specified as a URL of
> a document which contains the proxy information. MetaCard's built-in
> HTTP support supports the former, but implementing support for the
> latter is one of the things that the new script-based library will
> do.
> Regards,
> Scott
>
> > Any comments appreciated.
> >
> > Cheers
> > Dave Cragg
> > _____________________________________________
> > The LACS Centre (Business English Training Resources)
> > mailto:[EMAIL PROTECTED]
> > http://www.lacscentre.co.uk
> > _____________________________________________
>
> ********************************************************
> Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> MetaCard: You know, there's an easier way to do that...
>
> Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Regards, Pierre Sahores
WEB, DB, B2B & ASP design.
Because people develop knowledge from scratch
rather than being born with built-in knowledge,
we can adapt to different circumstances.
Sampson, Geoffrey. Educating Eve :
The "Language Instinct" debate.
London: Cassell, 1997 [1999].
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.