ZeroMq IRC Log

Sunday July 10, 2011

[Time] Name	Message
[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