I think the best option with Xtreams (http://code.google.com/p/xtreams/ ) is to rewrite client code. This is why the designers have chosen a set of new selectors. If we think it's time to remove some cruft, but still have late client adopters, we could also write a wrapper providing old Stream API in Xtreams Something like: 'foo' reading withStreamAPI Then replace ReadStream/WriteStream with such factory... Of course, replicating the whole zoo of specialized selectors of current Stream library is not an option IMO. Nicolas 2012/1/30 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On Jan 30, 2012, at 9:24 14AM, Stéphane Ducasse wrote:
<main.pdf>
Nice!
Some comments on the parts I'm most familiar with: 3.2 I agree, the nice parts in FS to me is the path manipulation API. Going back to pure ANSI-streams as provided by FSFileStream is not really an option. Since it's a clean break from FileDirectory & friends though, it might be the perfect time to introduce XTreams; -or it might be too much hassle to have to change both parts in existing code at once.
A good compromise would be to make it pluggable, using the existing Standard/MultiByteFileStreams by default, but making XStreams pluggable (on a use--by-use basis, so you can write new code with XStreams while maintaining old code where you have only had time to rewrite the path handling)
3.3 "Using ephemerons we can then simplify the Announcement and make sure that clients do not have to worry about weak or not registration." You still have to worry about whether you want weak or strong registration. "Do I have strict requirements for when the announcement should stop being delivered in relation to subscriber lifespan?" is still a valid question. What you don't have to worry about, is what _type_ of subscription (action blocks or message sends), you are allowed to use when registering weakly.
Ends with "In addition, " then nothing :)
Cheers, Henry