[JDEV] module development
What is the good way to develop a jabber module ? External (with JECL for example) or internal with the 'load' method ? And why ? thanks _ Le journal des abonnés Caramail - http://www.carazine.com
Re: [JDEV] module development
External components seem to be the better choice if you can use them. This leaves the core server to do what it was made for, routing xml, all processing is pushed out to separate apps. There is a limitation to the external component model right now, that is all messages destined for an external component must be addressed to that component. This means that it is hard, impossible to write a component that will log all traffic through the jabber server. For that job you need to use a jsm module, which is build into jsm.so. Depending on where you place your load configuration, you can receive every packet going through the server. There are steps being taken to change this, as of 1.4.2 you can copy (bcc) any jid on all presence changes, so maybe all packets or all messages or something is not far behind. Just my observations, please correct me if I am wrong. Glenn - Original Message - From: "Frederic FELTEN" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 13, 2002 6:01 AM Subject: [JDEV] module development What is the good way to develop a jabber module ? External (with JECL for example) or internal with the 'load' method ? And why ? thanks _ Le journal des abonnés Caramail - http://www.carazine.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] module development
> What is the good way to develop a jabber module ? External > (with JECL for example) or internal with the 'load' method ? > And why ? > > thanks It depends on what your goal is. An external connect component (a separate daemon that connects to the Jabber server as a component and not a regular client) is a nice way of making sure that even if your component crashes the Jabber daemon will live on and serve it's clients. So if you are building a complex system with many components that do many different things it's good. On the other hand the communication between the Jabber daemon and the component is through one socket only. This means that if one client requests a massive data chunk (or very long list) all other messages to and from that component will be queued, not good if you want multiple simultaneous clients to your component. I made this mistake when creating a Maildir component from which many clients could fetch email simultaneously. I hade to convert into a module since when more than 30 clients tried to fetch email containing large attachments, while as Jabber module I could start a thread per request. Also, if you create a module you get Jabber API's very nice memory pooling. So, the crash problem? You can have several Jabber daemons, I have one instance of Jabber only for my maildir module. If it should need to communicate with my Jabber daemon that has the IM modules I can route packets. I do this so that if my Jabber Maildir instance crashes, my clients will still have IM functions up and running. Those were my two cents! :-) /P ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] module development
Hi, How is creating a separate module and a module in a separate jabberd different? They both have to communicate via a socket to the 'main' jabberd, right? Wouldn't the advantage to have multiple threads be nullified? Greetz, Ralphm ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] module development
> Hi, > > How is creating a separate module and a module in a separate jabberd different? > They both have to communicate via a socket to the 'main' jabberd, right? > Wouldn't the advantage to have multiple threads be nullified? Only if your clients are forced to connect to only one jabberd. But in my case my clients use gabber to the "main" jabberd and a mutt-hack for the "maildir" jabberd. The only reason I have two Jabber daemons is that if the "maildir" jabberd crashes my clients still have gabber working fine. In those rare cases I would like to route from either jabberd the multi threading is nullified, allthough one might want to keep that option available. For instance, you could have the "maildir" jabberd as the "default" and it will always route IM stuff to the "main" jabberd. Doing the other way around will be innefficient since the purpose of having the "maildir" jabberd instance was to get multi threading capabilities. /P ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] module development
On Wed, Mar 13, 2002 at 11:01:52AM +, Frederic FELTEN wrote:
> What is the good way to develop a jabber module ? External
> (with JECL for example) or internal with the 'load' method ?
> And why ?
Further to the replies that have already been made, there's also
the point that writing an external component that will connect
over a jabber:component:accept stream (i.e. a TCP sockets based
component) will be independent of the API of the specific jabberd
backbone it connects to. Writing a component in the style of, say,
the JUD component that connects to the j.o server will mean that
you can only connect it to servers of the j.o server ('jabberd')
flavour.
dj
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] module development
On Wed, Mar 13, 2002 at 08:02:29AM -0500, Glenn MacGregor wrote: > > For that job you need to use a jsm module, which is build into jsm.so. > Depending on where you place your load configuration, you can receive every > packet going through the server. Well, that's not entirely true :-) If comp1.localhost sends a message to comp2.localhost, it goes directly there, does not pass through the JSM, does not collect 200 pounds. In the general scheme of things, although the JSM is a significant part of many a typical Jabber, it is, at the end of the day, "just" another component. The backbone will deliver a chunk according to who it's addressed to - the JSM has an address just as much as the comp2.localhost component (in the above example) does. dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
