Sunday July 10, 2011

[Time] NameMessage
[12:55] fredix hi
[12:55] fredix is it possible to push without waiting for a pull worker ?
[12:56] sustrik sure
[12:57] sustrik message passing is async
[13:00] fredix sustrik, I checked the taskvent.cpp and it waiting for the taskwork
[13:09] fredix sustrik, ok it's send with ZMQ_NOBLOCK
[13:32] pieter_hintjens sustrik: I wrote a long reply to your 4.x proposal
[13:32] sustrik hi!
[13:32] sustrik seen it
[13:32] pieter_hintjens hi
[13:32] sustrik of course, it'll be 3.0
[13:32] sustrik i just used 3.0 and 4.0 to refer to
[13:32] sustrik new API + IDENTITY
[13:32] sustrik vs.
[13:32] sustrik new API w/o identity
[13:33] pieter_hintjens also, 'identity' is confusing, you mean 'explicit identities', I assume
[13:33] sustrik ZMQ_IDENTITY option
[13:33] pieter_hintjens note that every month that passes without a stable 3.x release increases the risk it'll never exist
[13:33] sustrik in overall, 3.0 is almost ready
[13:34] sustrik so it's time to polish the feature set
[13:35] pieter_hintjens the constraint that says you can't modify the API except in major releases is artificial and not helpful in all cases
[13:35] sustrik isn't it just a numbering issue?
[13:35] sustrik anyway
[13:35] pieter_hintjens the rules have to support the process, not vice-versa
[13:35] sustrik do you believe new API + ZMQ_IDENTITY should be released?
[13:36] pieter_hintjens like i said, my advice is to release changes one by one and get them stable before starting new ones
[13:36] sustrik that's going to make binding maintainers' lives into hell
[13:36] pieter_hintjens the time-to-stability is the product of the number of new aspects
[13:37] sustrik lots of incompatible versions
[13:37] pieter_hintjens I don't agree
[13:37] pieter_hintjens those binding authors who have tried (pyzmq, czmq) have found it trivial
[13:37] pieter_hintjens no-one has provided counter evidence
[13:38] sustrik that's beause there are basically no versions so far
[13:38] sustrik what if there are 4-5 versions?
[13:38] pieter_hintjens ?
[13:38] pieter_hintjens 2 or 5 is much the same
[13:38] pieter_hintjens the step from 1 to 2 is the hard one
[13:38] sustrik imagint the #ifdef mess in the bindings
[13:38] pieter_hintjens and it was trivial
[13:38] pieter_hintjens look, as a binding author, I'm not speaking from theory
[13:39] pieter_hintjens and you aren't proposing 4-5 versions
[13:39] pieter_hintjens 3, afaics
[13:39] sustrik i have no strong opinon on this
[13:39] sustrik i am happy to release the 3.0 as is
[13:39] pieter_hintjens my advice, once more, is release code rapidly so you get feedback on it rapidly
[13:40] pieter_hintjens take that to maturity, and then start the cycle again for new changes
[13:40] pieter_hintjens no-one is using 3.x afaik
[13:40] pieter_hintjens and that's bad
[13:40] sustrik i need to drop identity to make any further changes
[13:40] sustrik so it's going to be 3.0.0
[13:40] pieter_hintjens do that in 3.1
[13:40] sustrik or 4.0, doesn't matter
[13:40] pieter_hintjens and only after 3.0 is stable
[13:40] sustrik the point is, who's going to maintain 3.0
[13:41] pieter_hintjens that's my advice, but of course you'll ignore it :-)
[13:41] sustrik you mean no new functionality until 3.0 is stable?
[13:41] pieter_hintjens that is what I said, yes
[13:41] pieter_hintjens you don't even know if the new functionality in 3.0 is accurate
[13:41] sustrik i see
[13:41] pieter_hintjens and it's guaranteed to have new bugs and holes
[13:42] pieter_hintjens you want one legacy, one stable, one experimental release, always
[13:42] sustrik sure
[13:42] pieter_hintjens get 2.1 to legacy status, 3.0 to stable, and then 3.1 can be the new experimental
[13:42] pieter_hintjens or 4.0, it doesn't really matter
[13:42] sustrik will you take care of 3.0?
[13:42] pieter_hintjens but you need to get your 80% mass of usership onto your stable version
[13:42] pieter_hintjens yes, once you stop making utterly random changes :-)
[13:43] sustrik goodo
[13:43] pieter_hintjens and once there's a mass of users
[13:43] pieter_hintjens I'll maintain 3.0, for sure
[13:43] sustrik then we can release it soonish
[13:43] pieter_hintjens the maintenance process is cheap and easy, as it should be
[13:44] pieter_hintjens i'm happy to see another dramatic shift for 4.0, that's fine, but only once 3.x is stable and safe
[13:44] pieter_hintjens it's unclear today whether removing identities is dramatic or not
[13:44] pieter_hintjens quite possibly, it's not a big deal at all
[13:44] sustrik for me it is
[13:45] pieter_hintjens I mean, for 0MQ users
[13:45] sustrik yeah, possibly
[13:45] sustrik no idea
[13:45] pieter_hintjens well, we have asked on the list and the general response was "meh"
[13:45] sustrik some people opposed the idea
[13:46] sustrik anyway, no ZMQ_IDENTITY removal, no new features
[13:46] sustrik i'm out of ideas what else can be added without messing with explicit identities
[13:46] pieter_hintjens the measure of stability is a good set of reported and resolved issues on a particular version
[13:47] pieter_hintjens afaics there haven't been many issues specific to new 3.x functionality
[13:47] sustrik none, i would say
[13:47] sustrik it's still unstable
[13:48] pieter_hintjens no-one using it is a bad thing, really
[13:48] pieter_hintjens let's aim to get 3.0 packaged as a new unstable release
[13:48] pieter_hintjens properly documented, etc.
[13:48] sustrik yep, i would like to do that
[13:49] pieter_hintjens I think subscription forwarding is the carrot
[13:49] sustrik yes
[13:49] pieter_hintjens so, I'll start on a release project for it
[13:49] sustrik it makes 0mq applicable for market data scenarios
[13:49] pieter_hintjens and start making packages
[13:49] sustrik wait a sec
[13:49] sustrik let's review it first
[13:49] pieter_hintjens sure, not today, I'm going to the beach with the kids first :-)
[13:50] sustrik ok, have a nice time :)
[13:50] pieter_hintjens I have a little time in July, after that it starts to get hectic
[13:50] pieter_hintjens let's aim for this week sometime
[13:50] pieter_hintjens people will bitch about abuse of github, as usual...
[13:50] pieter_hintjens :-)
[13:51] pieter_hintjens sustrik: I'll send an email to the list with some plans then...
[13:51] sustrik ok
[15:47] cremes sustrik, pieter_hintjens: fyi, i do use explicit identities in all of my code even though i don't *need* to
[15:48] cremes i use them for debugging ROUTER/DEALER topology problems by logging the envelope headers
[15:48] cremes so i can trace message flows
[15:48] cremes i could turn them off tomorrow and suffer no loss in functionality
[15:49] cremes it would just make debugging a bit more involved (but my topologies are stable now
[15:49] cremes so i won't have to do much more of that)
[15:49] cremes just throwing this info out here so you have more info on how identities were being used
[15:56] sustrik cremes: i would say that the debugging is a different, but valid use case
[15:56] sustrik let's think about how to do message tracing properly...
[15:58] sustrik in any case, pieter decided to maintain 3.0, so identities are going to stay for a while
[16:09] taotetek