Re: [caplisp-devel] httpsy porting

[James G. <an...@xn...>]

David Mercer wrote:
> Sorry for the very delayed replay, 3 math classes at once has been
> more of a load than I thought it would! Comments interspersed below. 

Yeah, well, having a 60+ hour a week day job also isn't conducive to
working on free software in my free time either.

> I'm actually kinda glad you're back to s48 for your efforts, as that's
> a direction I'd wanted to explore for a while, too. Even emailed jar
> about some things regarding such an effort a time or two.   I punted
> to image level confinement in my current caplisp aspirations for
> pretty much the reasons jar outlined in very good detail in your
> message (on elang I think) recently.  Or at least a decent subset of
> them!

If there's anything interesting/useful that he or you said, please
forword it if you can get permission.

>>So we've got some other tools to do the FFI generation for OpenSSL
>>and/or GNU TLS.  I'm only going to need a small part of the API to begin
>>with anyway.
> 
> That sounds like a great place to start.

I haven't made much progress lately.  I did get Scheffig up and running,
and that stuff is detailed on the Scheme 48 mailing list.

However, I've continued to run into problems with it, and until I spend
some more time studying it, I'm putting Scheffig on the shelf for now.

This was also prompted because the existing socket library for Scheme 48
doesn't expose the Unix file descriptors, just Scheme ports.

Whereas OpenSSL (*) expects to be handed Unix file descriptors, and it
makes the SSL connection on top of that.

So I'll need to create some wrapper functions which can extract the Unix
file descriptor (easy).  And then we'll also want to create a Scheme-ish
port interface on top of that. (also not hard)

That's probably about a day's work total.

What is inconvenient though, is that there are plans to re-vamp the
network programming library for Scheme 48, as part of a possible
re-unification with SCSH (**).

I'm thinking I just want to create the minimal possible interface to
OpenSSL, and then wait to see what happens with the networking API.

>>I'm also tempted to work on some kind of tool to automatically convert
>>modules for other Schemes (most notably Chicken and DrScheme) to make it
>>easier to import their libraries.  I'll need to hand-convert a few
>>first, to get a good feel for what that would require.
> 
> 
> Oh such a tool would be very, very sweet!

Yeah, but it will be a fair amount of work.  Perhaps it would be better
to support the "Common Scheme" effort, and try to get people to port
their libraries to that instead.

> I'm very interested to follow any/all progress you make with s48.  Let
> us all know when there's code to look at!

Will do.

James Graves

(*) I started first working with GNU TLS.  I downloaded their
documentation page, and started trying to compile the example code.
This didn't work for a couple reasons: missing functions (which I could
easily have fixed) and that all the structure names have changed between
version 1.0.x and version 1.2.x.  The documentation refers to 1.2, and I
have 1.0 installed on my Debian Sarge machines.  I could download and
install 1.2, and then point the compiler and linker at the new version,
but I didn't want to futz with it.

Meanwhile, I found some 9 year old demo code for OpenSSL, and after a
few very minor tweaks, it compiled, ran, and appears to function
correctly.  Huzzah for stable APIs!  Defintely using OpenSSL for now,
despite the license issues.

(**) So in this case, Scheme 48 is the Vulcans, and SCSH is the Romulans.