Discussion:
Call for discussion: current state of master
Jon Tara
2011-09-15 03:49:49 UTC
Permalink
This is a call for discussion about the current state of the master, as
well as future direction.

There's an elephant in the room, and we all seem to have been ignoring
it. Lucas announced on this list that he was abandoning the project back
in February. Given that there have been no real updates (save for
disabling from troublesome tests) in nearly a year and a half, and no
new tag or update to the version number or Gem since 0.5 since June of
2009, I think we can assume he meant it!

It's a shame, because although there are some new initiatives in XMPP
libraries for Ruby, the new ones mainly seem special-purpose (e.g. for
writing bots) and none seem as complete or comprehensive as XMPP4R. (If
you think I am wrong about this, please point me in a direction.)

I am willing to take over going forward, but mainly as as a "curator". I
don't plan to do extensive work on XMPP4R myself, except, of course, in
those areas where I have a need or interest. That need or interest would
be mainly in the areas of mobile applications, MUC, and PubSub.

Lucas has indicated that he prefers a name change, is reluctant to
hand-over the GNA stuff, and would prefer to see releases first. So, I'm
moving forward by at least putting a public repository out there for
consideration. For now, I'm keeping the name, but have labelled and
versioned my fork initially as 0.6pre1 for the convenience of those who
would like to give it a spin. (So you can easily install it side-by-side
using gem.) I'll rev it to 0.6pre2 when I've incorporated my BOSH fixes
in the master (see separate post.)

In any case, I am interested in hearing from others concerning the
current state of master: is there anything added since 0.5 that is
broken or that you feel should be removed?

(I am aware of one issue: the simple MUC client was changed to allow
history to be shut off. But the default is "no history", so this is an
incompatible change that will require a change in any existing client
applications. I plan on changing this so that the default is "all
history" as before, as well as allowing the user to specify the amount
of history, not just disabling it altogether.)

I'd also like to hear from others who are considering taking over
responsibility for releases, and/or have made significant
improvements/fixes that they would like to make public. Obviously, I
have an interest in incorporating any such work whether or not my fork
eventually becomes the "official" version.
Lucas Nussbaum
2011-09-15 05:59:30 UTC
Permalink
Post by Jon Tara
This is a call for discussion about the current state of the master,
as well as future direction.
There's an elephant in the room, and we all seem to have been
ignoring it. Lucas announced on this list that he was abandoning the
project back in February. Given that there have been no real updates
(save for disabling from troublesome tests) in nearly a year and a
half, and no new tag or update to the version number or Gem since
0.5 since June of 2009, I think we can assume he meant it!
Totally. :)
Post by Jon Tara
It's a shame, because although there are some new initiatives in
XMPP libraries for Ruby, the new ones mainly seem special-purpose
(e.g. for writing bots) and none seem as complete or comprehensive
as XMPP4R. (If you think I am wrong about this, please point me in a
direction.)
I am willing to take over going forward, but mainly as as a
"curator". I don't plan to do extensive work on XMPP4R myself,
except, of course, in those areas where I have a need or interest.
That need or interest would be mainly in the areas of mobile
applications, MUC, and PubSub.
Lucas has indicated that he prefers a name change, is reluctant to
hand-over the GNA stuff, and would prefer to see releases first.
I changed my mind about that. However, it probably makes sense not to
use GNA anymore, and rely only on github. But I can give you the admin
rights on the GNA project if you want them.
Post by Jon Tara
So, I'm moving forward by at least putting a public repository out
there for consideration. For now, I'm keeping the name, but have
labelled and versioned my fork initially as 0.6pre1 for the
convenience of those who would like to give it a spin. (So you can
easily install it side-by-side using gem.) I'll rev it to 0.6pre2 when
I've incorporated my BOSH fixes in the master (see separate post.)
In any case, I am interested in hearing from others concerning the
current state of master: is there anything added since 0.5 that is
broken or that you feel should be removed?
(I am aware of one issue: the simple MUC client was changed to allow
history to be shut off. But the default is "no history", so this is an
incompatible change that will require a change in any existing client
applications. I plan on changing this so that the default is "all
history" as before, as well as allowing the user to specify the amount
of history, not just disabling it altogether.)
I'd also like to hear from others who are considering taking over
responsibility for releases, and/or have made significant
improvements/fixes that they would like to make public. Obviously, I
have an interest in incorporating any such work whether or not my fork
eventually becomes the "official" version.
Thanks a lot for starting this work. I wish you a lot of success, and
I'll try to help when needed with the handover.

There are just a few things I wanted to say:
- xmpp4r-simple is really harmful to this project. You might want to
develop a strategy to get rid of it, such as detecting when it is
loaded together with xmpp4r.
- it could ease development to split xmpp4r into xmpp4r-core and
xmpp4r-addons. -addons could include everything that is related to
supporting XEPs that don't need anything special from core. That way,
it would slow down the development of -core, and it would help
stabilize it. The problem, of course, is to know where to draw the
line.

Lucas

Loading...