I keep getting this error. Any ideas as to why this is happening? I
am running r977 (don’t have time to update).
Can someone please just dike the entire jabber notification subsystem
out? We’ll start again from clean after 4.0. I’d do it myself, but I’m
stuck doing paing work at the moment.
I keep getting this error. Any ideas as to why this is happening? I
am running r977 (don’t have time to update).
Can someone please just dike the entire jabber notification subsystem
out? We’ll start again from clean after 4.0. I’d do it myself, but I’m
stuck doing paing work at the moment.
Alternatively could someone commit my patch which makes it all work?
It’s
been on the trac for quite some time now.
The main problem is that Typo went with Jabber4R, which is buggy.
Replace
that with XMPP4R, and everything works fine.
TX
P.S. If you’re going to throw out Jabber notification, please throw out
email notification too. I only use the Jabber one, after all, and
can’t imagine why anyone would want to be notified via email. ;-p
been on the trac for quite some time now.
The main problem I have with the whole Jabber notification scheme is
that it’s almost entirely test free. I prefer to view what’s in place as
a
spike, throw it away and start again test first with the benefit of
extra understanding from the first, failed solution. As I’ve explained
in my blog[1], I’m not totally averse (but getting more averse by the
day) to committing changes without patches, but only when those
changes are ‘mine’ because then I’ve at least got a chance of
remembering my intent.
Which is why I haven’t committed the big podcasting patch either –
It’s screaming out for a couple or three integration or functional
tests to stand as an explanation of what the patch does. Without that,
I haven’t the faintest idea if what the patch does is the right thing,
or just what it does. Show me tests and you show me what you intend.
The main problem is that Typo went with Jabber4R, which is buggy. Replace
that with XMPP4R, and everything works fine.
I just checked, and there’s a licensing problem with XMPP4R as well,
which means we can’t include it in the Typo distribution without
changing Typo’s license, which I’m not prepared to do. And I’m not
prepared to add an external dependency either.
Give me a patch, with tests, that degrades gracefully (it can simply
turn jabber notification off) if the absence of XMPP4R and I’ll jump
at the chance to apply it. Until then, I’d far rather see it taken out
for 4.0 rather than ship broken code.
P.S. If you’re going to throw out Jabber notification, please throw
out email notification too. I only use the Jabber one, after all,
and can’t imagine why anyone would want to be notified via
email. ;-p
I just checked, and there’s a licensing problem with XMPP4R as well,
which means we can’t include it in the Typo distribution without
changing Typo’s license, which I’m not prepared to do. And I’m not
prepared to add an external dependency either.
XMPP4R is released under the Ruby licence. I take it that Typo, a
project
written in Ruby itself, is incompatible with the Ruby licence. Nice bit
of
irony right there.
Just out of curiosity, how does one test a feature which by its very
nature
requires contact with a server somewhere? Is there a common Jabber
server
which unit tests might be able to connect to, which would always be
present
in order to test something like Jabber notifications?
The same problem exists with mail notifications, naturally.
One might say that you can stub the thing which sends the mail. But if
you
also stubbed the thing which sends the instant message, the existing
notification for Jabber would seem to be working, because the broken
code is
inside the method you would need to stub.
I just checked, and there’s a licensing problem with XMPP4R as well,
which means we can’t include it in the Typo distribution without
changing Typo’s license, which I’m not prepared to do. And I’m not
prepared to add an external dependency either.
XMPP4R is released under the Ruby licence. I take it that Typo, a project
written in Ruby itself, is incompatible with the Ruby licence. Nice bit of
irony right there.
Ah… according to the RAA page I looked at, it was GPL
licensed. However, on further investigation I see you’re right. Oops.
Er, then we have an old version. The current one is BSD.
Scott
On 4/14/06, Trejkaz [email protected] wrote:> -----BEGIN PGP
SIGNED MESSAGE-----> Hash: SHA1>>> On 15/04/2006, at 00:08 AM, Piers
Cawley wrote:>> > Trejkaz [email protected] writes:> >> >> On
Friday 14 April 2006 14:32, Piers C. wrote:> >>> I just checked, and
there’s a licensing problem with XMPP4R as well,> >>> which means we
can’t include it in the Typo distribution without> >>> changing Typo’s
license, which I’m not prepared to do. And I’m not> >>> prepared to add
an external dependency either.> >>> >> XMPP4R is released under the Ruby
licence. I take it that Typo, a> >> project> >> written in Ruby itself,
is incompatible with the Ruby licence.> >> Nice bit of> >> irony right
there.> >> > Ah… according to the RAA page I looked at, it was GPL> >
licensed. However, on further investigation I see you’re right. Oops.>>
Actually, on the subject of the GPL, what about bluecloth? vendor/>
bluecloth/LICENCE is GPL2.>> TX>> -----BEGIN PGP SIGNATURE-----> Versi!
on: GnuPG v1.4.2.2 (Darwin)>>
iD8DBQFEP7JCuMe8iwN+6nMRAhwCAJ4+ulXUOAE1sdVO2gLl41yMdBGbOQCfUIYG>
th5LJ4PLzPVuGgEKBR+KkWY=> =vCm+> -----END PGP SIGNATURE----->
_______________________________________________> Typo-list mailing list> [email protected]> http://rubyforge.org/mailman/listinfo/typo-list>
Am I correct in remembering that Jabber’s a peer to peer protocol?
Not really. It’s a hybrid protocol–while peer-to-peer connections are
used for some functions, the core presence and messaging involves
connections to a server.
Presumably you can just fire up a client object in some sort of accept
connections mode and use that as your jabber server.
Unfortunately, the Jabber protocol is somewhat baroque. The designers
decided to make it use stream-based XML, instead of plain text like most
other Internet handshaking protocols. This makes it hard to build a
Jabber server (or client for that matter)–you can’t use validating XML
parsers, for example, because you need to be able to parse fragments
that don’t constitute a complete document with a DTD. It’s about the
second worst Internet protocol I’ve seen. (The worst is SyncML.)
Anyhow, I think it’s pretty funny to be rejecting code based on lack of
tests, when there’s an almost complete lack of documentation.
requires contact with a server somewhere? Is there a common Jabber server
which unit tests might be able to connect to, which would always be present
in order to test something like Jabber notifications?
Am I correct in remembering that Jabber’s a peer to peer protocol?
Presumably you can just fire up a client object in some sort of accept
connections mode and use that as your jabber server.
I’d also suggest looking at how the XMPP4R tests themselves do
it. Essentially, you need to check that typo is sending the right
stuff to the library, so you might be able to get away with stubbing
the entire connection.
The same problem exists with mail notifications, naturally.
One might say that you can stub the thing which sends the mail.
That’s pretty much what we do.
But if you also stubbed the thing which sends the instant message,
the existing notification for Jabber would seem to be working,
because the broken code is inside the method you would need to stub.
That being a method in the library yes? Presumably the library we’re
planning on replacing jabber4r with comes with its own test suite? If
so, we just trust that it will do the right thing given the right
input. What we don’t have at the moment are any tests to ensure that
it does get given the right input.
Documentation is as essential to good software as tests.
Actually, it’s probably more essential, because without
documentation telling
you how things are supposed to work, there’s no way to write new
tests.
Unless you have convinced yourself that you don’t need documentation
because your code is so readable and you have lots of tests that show
what your code is supposed to do. I don’t buy it though.
Documentation is as essential to good software as tests.
Bollocks. I’d take good tests over good documentation any day of the
week.
Well you’re wrong, and we’ve just had a clear example of why you’re
wrong discussed on the list.
No amount of unit tests was ever going to tell people that
render_component was deprecated, and that render_sidebar should be
used instead. Hence, people used render_component to render sidebars
in all those fancy competition themes, and they all broke.
End result: poor typo reliability.
Documentation is as essential as unit tests when you have APIs being
used by people who aren’t the developers of the API. Anyone who
doesn’t see that is a hack.
Documentation is as essential to good software as tests.
Bollocks. I’d take good tests over good documentation any day of the
week.
Well you’re wrong, and we’ve just had a clear example of why you’re
wrong discussed on the list.
Well, up to a point. Yes, our public APIs could do with being better
documented (and as you’ll notice from another thread on this list, I’m
working on making the whole theming API a good deal more
understandable/explainable than it is now and I’ve just written[1] the
beginnings of some documentation of the upcoming new style sidebar
API), but that doesn’t make your original observation anything but a
non sequitur. Give me a codebase with good tests and lousy
documentation and I can write the documentation reasonably
quickly. Give me a codebase with apparently excellent documentation
and no tests and I will have very little confidence that it does what
the docs say. Which is why I’m far more insistent about tests than I
am about docs.
No amount of unit tests was ever going to tell people that
render_component was deprecated, and that render_sidebar should be
used instead. Hence, people used render_component to render sidebars
in all those fancy competition themes, and they all broke.
I don’t think the render_component version was even deprecated at the
time of the competition. It should have been, because forcing theme
designers to drop in boilerplate structural code like that is just
asking for trouble. I only broke it relatively recently because I’ve
been rejigging the sidebar structure to make it slightly less
detestable[2]. I’m pretty sure that I mentioned that render_sidebar
was the preferred way when I added it, both here and in the change
log.
End result: poor typo reliability.
Documentation is as essential as unit tests when you have APIs being
used by people who aren’t the developers of the API. Anyone who
doesn’t see that is a hack.
Because calling your interlocutor a hack is always going to convince
him you’re right.
detestable: incabable of being automatically tested
Give me a codebase with good tests and lousy
documentation and I can write the documentation reasonably
quickly.
Yes, but you haven’t. And until you do, you’ll have a bad codebase,
because the API’s requirements and contracts will be undocumented. This
in turn will mean people won’t feel confident using the code. If you’re
lucky, all you get is few 3rd party plugins or themes. If you’re
unlucky, you’ll get duplicate code and bloat.
Give me a codebase with apparently excellent documentation
and no tests and I will have very little confidence that it does what
the docs say.
Which is why I didn’t say documentation was an alternative to unit
tests.
I view both as necessary. I’d point out that you’re the one taking an
extreme position here, apparently saying that only one of them is.
I’m pretty sure that I mentioned that render_sidebar
was the preferred way when I added it, both here and in the change
log.
Need I mention that change logs and mailing list traffic are not
documentation?
Because calling your interlocutor a hack is always going to convince
him you’re right.
