Xtreams in Pharo 3

"Sven Van Caekenberghe"<[hidden email]> wrote:
Yes, it's taking embarrassingly long, but we are inching forward. I've made some progress with the Cypress experiment, the github project (https://github.com/mkobetic/Xtreams) now has branches for VW, Pharo and ST/X. The branches still have differences that shouldn't be there, but we're getting there. It would be fantastic if Sean or somebody would meet me halfway with the Filetree tweaks for prefix to namespace mapping. Anyway, I still intend to get there eventually, but I have to admit that I'm spending a lot less time in Smalltalk these days. FWIW I definitely haven't lost interest though.

That said, I think all three ports are relatively solid (Thanks Nicolas, Frank, Jan, ...!). The core components haven't changed much in a while (although there are few things that I would like to improve there, I'll create issues for those on google code eventually), so there shouldn't be much catching up to do. Most of the recent activity was building on top of the core, that's primarily where VW is ahead (multiplexing, compression, ...) and where more should be done (e.g. compression can offer a lot more beyond just deflate).

> Maybe, you and Nicolas should sync up a bit.

I'll also try to answer any questions that I'll notice on the mailing lists. I'm monitoring issues on google code, feel free to raise anything there as well.

Martin

On 20 Nov 2013, at 17:18, Frank Shearar <[hidden email]> wrote:

> It's Pharo specific at the moment AFAICT because it refers to
> FileHandle and FileReference, while the upstream repo uses
> FSFileHandle and FSFileReference. The conversation's partly at
> https://code.google.com/p/xtreams/issues/detail?id=2

Thanks, Frank, for the explanation. Conclusion: for now it can be consider Pharo only (but given some class renames, it should be broader).

With/without prefixes is one aspect, forking/not-forking another.

Like I said, and like you acknowledged, it is possible to keep things together, but it requires real, continuous effort from all sides.

Sven

If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms.
Sorry but we have too many of them and we do not want to have strings attached.
if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo.

I'm not sure that people can understand that but this is important. And we do not do that for the sake of it.
As one of the keeper of the core I do not want to have to think about systems I do not know.

Stef

On 23 November 2013 09:41, Stéphane Ducasse <[hidden email]> wrote:
> If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms.
> Sorry but we have too many of them and we do not want to have strings attached.
> if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo.
>
> I'm not sure that people can understand that but this is important. And we do not do that for the sake of it.
> As one of the keeper of the core I do not want to have to think about systems I do not know.

I completely understand the desire to do this. Every other platform
maintainer agrees with you. That's why hardly anything ever gets done
between the dialects, and why those that do maintain cross-dialect
libraries probably (I know I certainly do) curse all the platform
maintainers for being so insular. This problem even has a name: the
tragedy of the commons.

frank

On 23 Nov 2013, at 11:02, Frank Shearar <[hidden email]> wrote:

@Stef - yes, I understand, but that is only an issue if/when we actually do include it for real, and if/when we actually start using it (remember Nile, it was there, but never used)

For now, I think it would be better to move together (remember, this code started and lives in VW), when we encounter insurmountable problems with compatibility, then we’ll deal with them.

Yes I think that treams will have  a better chance

> For now, I think it would be better to move together (remember, this code started and lives in VW), when we encounter insurmountable problems with compatibility, then we’ll deal with them.

Sure.