If one group of guys would take the lead we could introduce XTream in 2.0 and slowly start to integrate and deprecate slowly the old streams. Who is interested in that?
Stef >>>> Tx >>>> >>>> now there is a difference between adjustments and fully new API and I >>>> would have preferred adjustments. >>>> >>>> Stef >>> >>> IMO, Xtreams design is simply superior. >> >> +100. >> I gave up on trying to mold the current Streams into something a bit more >> reasonable and still be backwards compatible quite some time ago. >> >> That other thread about Converters? >> Totally related. For example, you can't do what Sven did in the Zn >> converters without breaking backwards compatability. Nor could you do it >> reasonably fast in the general case, since fast string -> bytearray >> streaming works for some streams, but not for others. (which, I guess, is >> one reason why the legacy converters do string -> string.) >> >> IMHO, Xtreams would be a perfect fit to go with the new FileSystem as well. >> (using compositing on top of a "dumb" terminal) >> > > Quite sure that it is highly ranked in Colin's plans. > >>> But i agree, we cannot throw existing streams out.. too much things >>> tied to them, and rely >>> on using stream protocols. :( >> >> Well, one*could* try to introduce something akin to the Zn HTTPClient >> compatability protocol, strictly speaking what you can do with Xtreams is a >> superset of what Streams currently do. >> The problem is all the moronic quirks of the current Streams, and clients >> potentially relying on that behaviour. >> >> Cheers, >> Henry >> >> >> >
