(usagi-users 03519) Re: Porting SUnet to s48; network API convergance

Andreas Rottmann <[email protected]>
Newsgroups gmane.linux.ipv6.usagi.users
Message-ID <87zmpkusse.fsf__3488.58895381472$1128784840$gmane$org@ivanova.rotty.yi.org>
Andreas Bernauer <[email protected]> writes:

> On 10/7/05, Andreas Rottmann <[email protected]> wrote:
>> 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:
>>
>> 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'm currently not so much into SUnet and scsh, but what's the point in
> porting SUnet from scsh to Scheme48 and at the same time breaking
> backwards compatibility? I am not sure if I understand you correctly:
> when people want to add something to SUnet, will they have to write
> one version for scsh and one version for Scheme48?
>
If I understood Mike Sperber correctly, he has this steps in mind:

1) Clean up the network API in scsh

2) Rebuild that API on s48 - on that point scsh and s48 have
   compatible network interfaces

3) Port SUnet to the new network API

I would be glad if he could comment that this is really what he has in
mind, or correct me, since I'm not sure.

Cheers, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | [email protected]
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

Make free software, not war!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.