[JDEV] Net::Jabber vs. Jabber::Connection?

[Piers Harding]

Jabber::Connection vs Net::Jabber is a matter of taste.  It depends
whether you want a style and construct forced upon you for doing node
manipulation or not.  J::C allows you to do what you want - including
getting into trouble ( very Perlish if you ask me ), where as N::J tries
to express the Jabber Protocol in Perl, and therefore must enforce the
rules of it.

Personally I prefer to a more free flowing format - but as I said it is
a matter of taste ( J::C was invaluable for prototype work for pubsub
JEP24 - which is after all defining new protocols ).

As for having to repeat code again and again, perhaps that is a style
issue too.  Explore Larry Walls programming characteristic of Laziness.

Also, as far as threading goes Perl 5.8 is almost upone us ( RC1 has
just been released ), with a completely new threading model - it will be
very interesting to see what that brings.

Cheers.


On Sun, Jun 02, 2002 at 12:40:55AM -0600, Nicholas Perez wrote:
> I have actually used both libs to a very indepth degree. JabminRPC in 
> its short lived life has been written in J::C and then rewritten in N::J.
> 
> J::C is really nice for things other than jabber since it depends 
> strongly upon XML::Parser, and that allows you to basically parse things 
> other than jabber packets (like the jabber.xml config file) in an xpath 
> like way.
> 
> I also really like N::J for those really high level abstractions. I 
> wrote a simple webpresence bot using N::J and the part that took the 
> longest was talking via DBI and DBD::ODBC to MySQL. I had the jabber 
> connection up and running in under 2 minutes.
> 
> But alas both have flaws too. After while you get tired of 
> typing/cutting/pasting, all of those methods with J::C to accomplish the 
> simple things that N::J does in one method. As for N::J Everything is an 
> object and you only get objects back, and that can be cumbersome with 
> things that are not fully implemented, such as XDB(understandable since 
> its not written into a JEP or anything anywhere. No official means no 
> support), that you could easily just get a jabber node and parse it out 
> via J::C.
> 
> The only major problem right now with _both_ libs, is the complete lack 
> of asynchronous parsing. This means the major bottleneck in your perl 
> apps is the parser and you must wait in the queue to get parsed. Part of 
> that issue falls upon perl's inability to be properly threaded. And this 
> in turn leads people to write parsers that are explicitly blocking 
> because of the serialization.
> 
> But overall, I love the work and love that goes into these libs. It 
> enables anyone to jump into jabber programming and to add jabber 
> abilities to just about anything that has a perl interface.
> 
> DJ Adams wrote:
> > On Sat, Jun 01, 2002 at 04:10:51PM -0500, Ryan Eatmon wrote:
> > 
> >>You could try Process(0) to wait 0 seconds (ie. exit immediatly).  As 
> >>for being odd that Process() blocks, this is the same behavior as many 
> >>other Perl modules (IO:Select comes to mind first).  I would argue that 
> >>Jabber::Connection is the odd man out.
> > 
> > 
> > Why?
> > 
> > J::C's process() uses IO::Select (specifically the can_read() function).
> > The behaviour is the same - it blocks for up to X seconds waiting for
> > something to be available. Calling process() (i.e. with no explicit
> > value) just makes the function assume 0 seconds.
> >  
> > 
> >>As for the differences between the two.  DJ wrote Jabber::XXXXXX as an 
> >>exercise and is slowly adding more to it.  Net::Jabber is meant to be a 
> >>100% protocol compatible and high level implementation (in other words 
> >>GetFrom() is high level as it hides the guts from you).
> > 
> >   
> > It did start out as an excercise but turned out to be the module I was
> > looking for too ;-) It's different to N::J in that it's a lowlevel
> > lightweight approach. Rather than include high-level functions like
> > GetFrom(), it allows you to build your own (the equivalent here is 
> > attr('from')) using the NodeFactory module which was loosely aimed to
> > reflect the API of the xmlnode library in the open source Jabber server.
> > It gives you the flexibility to manipulate the nodes of the Jabber XML
> > protocol as you see fit.
> > 
> > The examples you see on some of my web pages are with N::J as that was
> > what I was using at the time. 
> > 
> > Although I've seen examples of people using both J::C and N::J together,
> > it's usually the case that people will find one or the other that they
> > feel comfortable with (bottom-up vs top-down approaches). 
> > 
> > Cheers
> > dj
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> -- 
> Nick
> 
> JabminRPC Developer
> JabberSMTP Developer
> ChatBot's B1tch
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev