Gmane
From: Andreas Rottmann <a.rottmann <at> gmx.at>
Subject: (usagi-users 03517) Porting SUnet to s48; network API convergance
Newsgroups: gmane.linux.ipv6.usagi.users, gmane.lisp.scheme.scsh.devel
Date: 2005-10-07 10:38:19 GMT (3 years, 38 weeks, 5 days, 15 hours and 38 minutes ago)
Hi!

Since I'd like to be able to run SUnet on Scheme48, I have wondered
what the best way would be to achive this; here are excerpts of my
exchange with Michael Sperber:

,----
| Andreas Rottmann <ar <at> visotech.at> writes:
|
| > [...] These ideas and patches are all somewhat related to the effort
| > of porting scsh to Scheme48. I'm also interested in details on that,
| > since I want to have SUnet available for Scheme48 and that would
| > mean porting some scsh libraries/infrastructure. Could you please
| > point me to information on the porting process, so I can get
| > involved?
| 
| That's a handful of questions.  I'm not sure I can answer all of them
| well:
| 
| The general plan with scsh and Scheme 48 is to clean up the scsh APIs
| one by one.  The network API is high on that list, and indeed running
| SUnet on Scheme 48 is among our plans.  For that to happen, what we
| need to do is overhaul the scsh networking API---to clean it up, and
| to fit better with Scheme 48 conventions.  First and foremost, that
| means turning the enumerations into finite types, I think.  The best
| way to do it is probably to make the changes on the scsh trunk, and,
| when the code is ready there, merge it over.  (We also have plans to
| coordinate the network API with the PLT people, but that's probably a
| bit further off.)  So, if you want to help, submitting patches to scsh
| (coordinating with the scsh-hackers list) would probably be the
| appropriate first step.
`----

So, as a first step, I'm posting this here as a heads-up, and to ask
wether any efforts in that direction have already been undertaken or
are planned. FWIW, I've created an GNU Arch archive corresponding to
the scsh CVS trunk, and will branch from that, since CVS
branching/merging is mostly unusable. As Michael Sperber already
indicated, a first change will be converting the network constants
(e.g. protocol-family/*) to finite types. Since currently these
constants are hardcoded to match the constants used in the
corresponding C API, my idea was to have a platform-specific mapping
procedure, e.g. PROTOCOL-FAMILY-≥OS-INTEGER, that maps the finite type
instances to their C constant counterparts.

Of course these changes will break backwards compatibility, hence code
using the network API must be adapted or the old interface
retained. I'd like to know the stance of the scsh hackers on that one,
as well as how to coordinate with the SUnet hackers to get SUnet moved
to the new API.

Also, I would be grateful if I could get more details wrt. the
coordination with the PLT people.

Cheers, Rotty
-- 
Andreas Rottmann         | Rotty <at> ICQ      | 118634484 <at> ICQ | a.rottmann <at> gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Python is executable pseudocode, Perl is executable line-noise.