> > (Or am I alone in being willing to accept a departure from CL:s > > standard streams?) > > My guess is that you are ;-) I don't believe its impossible to > create a (very) useful network library on top of CL streams - > especially if Grey is taken as a given.
Maybe not impossible, but I have a feeling it will be difficult to work out all the kinks while operating within the CL spec and what can reasonable be expected of implementations. I might have stated things a bit over-critically in my last post. To restate: I am wondering whether it might be a good idea to define an independent interface where one is free to break conventions that would otherwise be limiting. Even if this is done, it does not mean that there would not be fully possible (and certainly important) to also provide a CL stream interface to it. (Even if only the CL stream interface is used to begin with, one would still pretty much need support for grey streams, simple streams or something similar that allows one to extend stream behavior. Given this, implementing such behavior on top of a newly created unified interface would be no different than implementing it on top of the implementations native interface (e.g., sb-bsd-sockets)). > Whilst it might be out of scope for a Gardener's project, I > personally think we should go the LispM route in a library of > this kind and integrate pathnames and network transports back > together; then it would be possible to get back the natty > host / transport negotiation type stuff that was done on that > platform. I will confess to having no experience whatsoever with that. > This is a longer-term goal for me, and one that is dependent on > networking libraries that deal in terms of strictly CL-type > streams (i.e. ones that can be used by the standard CL methods > that operate on streams). I don't see this as a problem (see above about implementing it). I too would consider it a basic requirement. But while it would be required, I do not know that it would be *sufficient*. > I don't know of any Lisps that support MP that don't push something onto > *features*. All we need do is provide '*threaded-p*' which > examines the appropriate feature for the underlying Lisp I guess. As long as its part of the "standard" unified API and thus portable. > That > said, several of the methods you'd expect to find in an MP library could > degrade gracefully into non-threaded code; some suggestions for these > can be found in the CLIM 2 spec: > > http://mikemac.com/mikemac/clim/clim-sys.html#32.2 How would you be able to degrade low-level concurrency primitives? (Did I miss something on that page?) I can see degrading certain high-level tools. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
