On 10/23/06, nick thomas jesuswaffle@gmail.com wrote:
On 10/22/06, Erik Huelsmann ehuels@gmail.com wrote:
Looking at ABCL and flexi-streams though, I do see a problem: ABCL doesn't have a generic function close, but defines STREAM-CLOSE instead... At least flexi-streams 0.5.10 seems to depend on close, open-stream-p and maybe others too, to be generic functions, not just defuns...
Well, ABCL isn't in wide use anyway and not going very fast development, but, well, I could ask around with the developers what to expect there. It would indeed be too bad not to be able to support :external-format there, but that's an option too (just ignore the external-format in case of ABCL). We need to make sure to document that though.
That sounds good to me.
Anyway, feel free to ignore me; your way would work fine, as well. I'm just throwing out alternatives here.
Oh! No! I'm not ignoring you! Having these discussions with myself is a lot harder than having them with you ;-) I do have my own opinions, but talking about pros and cons is a lot better than hitting a wall. You're really helping usocket forward.
One minor concern, though: does it make sense to add a whole new mandatory dependency (two, in fact) for a relatively obscure feature like this?
I think that's funny: :external-format should have become a major issue for all lisp implementations by now. i18n is really a 'must' for any self-respecting application these days. So, any platform worth developing on should support it.
Now, I realize I'm backpedaling here, but how about we require the user, if they want to use flexi-streams, to just create one themselves from the raw streams that we return?
Well, that does simplify matters: if we do that, we only need to support :element-type to make sure people can create the binary streams which flexi-streams needs for its input.
This is a trade-off: it makes things easier for people who don't need :external-format or bivalent streams, but it makes things harder for people who do. It would also mean that the :external-format flag to OPEN-STREAM would remain useless, but, in trivial-sockets itself, it only works under CLISP, anyway.
I do like Douglas's idea too: those implementations which do not support external-format or bivalent streams, will require flexi-streams. Implementations which *do* support that can use their internal system.
However that would loose portable external format specifications. It should be quite trivial to write a mapping from a general spec to implementation defined ones though.
The other thing we will probably loose is bivalence. On IRC I was told SBCL will allow stream-read-byte/read-byte on character streams, effectively making them bivalent, but I'm not sure for any of the other implementations. There is (in contrast with external-format) no (setf element-type) method in the standard, so this behaviour will be implementation specific...
Maybe we can find out by creating a simple test-case to run on all supported platforms and see if each platform effectively provides bivalent streams?
bye,
Erik.
PS: I created a generic function in ABCL and it took a measurable amount of time on my P4-3Ghz 1GB RAM, so I indeed think the ABCL developers are right: ABCL is dead slow.