Project

General

Profile

Evaluating Tigase for a custom plugin (a sort of gateway): some questions

Gabriel Rossetti
Added over 4 years ago

Hi everyone,

I am evaluating Tigase for a project, before I was thinking of using Vysper but I am nervous now because of it's lack of maturity, support, documentation and lack of a community. Previously I have used ejabberd in a project close to this one but one requirement this time was only java is allowed. I have looked at Openfire too, but it is missing many features I may need later on, its documentation is quite good though. Tigase has a good doc too (but no JavaDoc?) and a forum with lots of questions and lots of answers (I have gone though all of them already and saved the ones I will need for later).

The project I have consists of a server (Tigase for example) that has a custom module that behaves like a gateway that receives non-XMPP msgs and does something with them and then pushes a msg (probably as an IQ reply?) to all of the connected the XMPP clients (using PubSub?). The clients can interact with this module by sending commands and receiving replies (Ad-hoc Commands?).

I was thinking of writing a Tigase plugin for this (and not a component). The "messages" are not chat messages but commands which is why I am thinking of using IQs instead of messages. I read in the forum that accessing the DB in a plugin slows it down (logical) but I don't have a huge amount of clients or messages so I am not worried about that. I also don't need presence and the only "buddy" the clients need is the server. I am not sure if I really need a roster, if so I read on the forum that I can use a dynamic roster and only add the server).

Would Tigase be a good fit for this? Any things to watch out for?

Thanks,

Gab


Replies (6)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 4 years ago

Gabriel Rossetti wrote:

Hi everyone,

I am evaluating Tigase for a project, before I was thinking of using Vysper but I am nervous now because of it's lack of maturity, support, documentation and lack of a community. Previously I have used ejabberd in a project close to this one but one requirement this time was only java is allowed. I have looked at Openfire too, but it is missing many features I may need later on, its documentation is quite good though. Tigase has a good doc too (but no JavaDoc?) and a forum with lots of questions and lots of answers (I have gone though all of them already and saved the ones I will need for later).

We do have JavaDoc as well. However, right now we do not publish it. So, at the moment, you have to get sources and generate JavaDoc for yourself. This will change soon. We are working on a new website, dedicated specifically to publish documentation for all our projects, Tigase server code, all components, clients code, etc... You can have a look a what we have right now here: http://docs.tigase.org

We expect to have it fully functional and with complete set of documents by the end of the month.

The project I have consists of a server (Tigase for example) that has a custom module that behaves like a gateway that receives non-XMPP msgs and does something with them and then pushes a msg (probably as an IQ reply?) to all of the connected the XMPP clients (using PubSub?). The clients can interact with this module by sending commands and receiving replies (Ad-hoc Commands?).

I was thinking of writing a Tigase plugin for this (and not a component). The "messages" are not chat messages but commands which is why I am thinking of using IQs instead of messages. I read in the forum that accessing the DB in a plugin slows it down (logical) but I don't have a huge amount of clients or messages so I am not worried about that. I also don't need presence and the only "buddy" the clients need is the server. I am not sure if I really need a roster, if so I read on the forum that I can use a dynamic roster and only add the server).

Would Tigase be a good fit for this? Any things to watch out for?

The question: do it in a plugin or in a component is quite common. It all comes down to the specific requirements.

Writing plugins is simple and easy. Deploying it is easy as well. Plugins have access to users online metadata. However, there are some limitations.

Plugins process specific packet types on behalf of a user*. That is packets which are sent to a user or received from a user. You cannot send a packet to a plugin. Plugin does not have an XMPP address. Also, plugins run inside the main Tigase server instance, that is inside *SessionManager component. Therefore it is not easy to distribute load if the plugin has to process a lot of data. This is problematic, especially if you need to access DB during processing. Let's say DB query takes 10ms, then the maximum traffic the plugin can handle is 100 packets /second. If you get more, plugin starts queuing packets, until queue overfill and packets are lost.

Components are more complex and require a bit of more work but there are significant advantages. You can deploy component as internal or external component, even on a different machine. Moreover, you can deploy many instances of the component on different machines if you need to distribute the load. This is transparent for the developer. So you do not have to think or worry about this during implementation time. Components have own JID address, so you can send packets directly to component. Components can handle admin ad-hoc commands - this is built-in to the component framework, so you do not have to implement it. It is already there. This gives you an opportunity to control your component in very different way. All at run-time.

Added by Gabriel Rossetti over 4 years ago

We do have JavaDoc as well. However, right now we do not publish it.

So, at the moment, you have to get sources and generate JavaDoc for

yourself. This will change soon. We are working on a new website,

dedicated specifically to publish documentation for all our projects,

Tigase server code, all components, clients code, etc... You can have a

look a what we have right now here: http://docs.tigase.org

We expect to have it fully functional and with complete set of

documents by the end of the month.

Thanks!

Writing plugins is simple and easy. Deploying it is easy as well.

Plugins have access to users online metadata. However, there are some

limitations.

Plugins process specific packet types on behalf of a user. That is

packets which are sent to a user or received from a user. You cannot

send a packet to a plugin. Plugin does not have an XMPP address. Also,

plugins run inside the main Tigase server instance, that is inside

SessionManager component. Therefore it is not easy to distribute load

if the plugin has to process a lot of data. This is problematic,

especially if you need to access DB during processing. Let's say DB

query takes 10ms, then the maximum traffic the plugin can handle is 100

packets /second. If you get more, plugin starts queuing packets, until

queue overfill and packets are lost.

I don't understand..when a client requests his roster for example, this

is a plugin, the client asks the server and not another client. I

understand that the server in this case doesn't have a JID but the

client has a direct connecting with it so it is not needed. If I want to

send a custom Ad-Hoc Command to the server and for it to do something,

for example:

(Psudo-xmpp)

C: <iq type='execute' action='sum'><args type='list' subtype='int'>1, 2, 3, 4</args></iq>
S: <iq type='result' status='completed'><data type='int'>10</data></iq>

a plugin couldn't do this? Or are you saying that the plugin has some

sort of pseudo-user and a component does not?

Components are more complex and require a bit of more work but there are

significant advantages. You can deploy component as internal or external

component, even on a different machine. Moreover, you can deploy many

instances of the component on different machines if you need to

distribute the load. This is transparent for the developer. So you do

not have to think or worry about this during implementation time.

Components have own JID address, so you can send packets directly to

component. Components can handle admin ad-hoc commands - this is

built-in to the component framework, so you do not have to implement it.

It is already there. This gives you an opportunity to control your

component in very different way. All at run-time.

Ok, what is the difference in between a plugin and an internal component? I don't want an external component as I was asked not to distribute the server, like I said before, the number of messages is small compared to a chat system, I am talking of less than 50k msgs a day. I was thinking on leveraging on Tigase's stability and extendability (via plugins or whatever), to use it as a base and not have to worry about the lower-level stuff.

Thanks,

Gab

Added by Gabriel Rossetti over 4 years ago

Hmmm, is a plugin more like a hook, where you can do processing on a msg (for example an archive plugin could send all incomming msgs to an external database) or embellish a msg, etc? Then a component adds new functionality not linked to processing msgs that transit through the server? If this is the case then the roster is a component and not a plugin, is that correct? But the offline message store could be a plugin?

Thanks,

Gabriel

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 4 years ago

I don't understand..when a client requests his roster for example, this

is a plugin, the client asks the server and not another client. I

understand that the server in this case doesn't have a JID but the

client has a direct connecting with it so it is not needed.

In fact, the server does have a JID. Server's JID is his domain/virtual host you use for connecting to the server. This is domain part of the user's JID.

Please also note, plugins are executed by SessionManager component which does have own JID, so in theory you can send a direct packet (command)

to SessionManager component, or any other Tigase's component.

If I want to

send a custom Ad-Hoc Command to the server and for it to do something,

for example:

(Psudo-xmpp)

[...]

a plugin couldn't do this? Or are you saying that the plugin has some

sort of pseudo-user and a component does not?

Plugin can do this. However, we included ad-hoc commands functionality as a core of a component framework. So you do not need to

write a plugin to execute commands. Commands use scripting APIs and can be loaded directly to a component.

Plugin has some limited to data structures in Tigase server. Component has more flexible access, therefore executing admin commands

within component context, instead of plugin makes more sense.

Components are more complex and require a bit of more work but there are

significant advantages. You can deploy component as internal or external

component, even on a different machine. Moreover, you can deploy many

instances of the component on different machines if you need to

distribute the load. This is transparent for the developer. So you do

not have to think or worry about this during implementation time.

Components have own JID address, so you can send packets directly to

component. Components can handle admin ad-hoc commands - this is

built-in to the component framework, so you do not have to implement it.

It is already there. This gives you an opportunity to control your

component in very different way. All at run-time.

Ok, what is the difference in between a plugin and an internal component? I don't want an external component as I was asked not to distribute the server, like I said before, the number of messages is small compared to a chat system, I am talking of less than 50k msgs a day. I was thinking on leveraging on Tigase's stability and extendability (via plugins or whatever), to use it as a base and not have to worry about the lower-level stuff.

I suggest you look at our online documentation. Here is an answer to your question above: http://www.tigase.org/content/basic-information

More details are available throughout the whole development guide.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 4 years ago

Gabriel Rossetti wrote:

Hmmm, is a plugin more like a hook, where you can do processing on a msg (for example an archive plugin could send all incomming msgs to an external database) or embellish a msg, etc?

This is correct. Pausing are generally responsible for handling a specific protocol, protocol parts or protocol extension - roster handling, presence, message, vcard, privacy lists, .....

If this is the case then the roster is a component and not a plugin, is that correct?

I do not understand the sentence above, roster protocol is handled by a plugin in Tigase.

But the offline message store could be a plugin?

This is actually realized by a plugin and a component. The plugin intercepts messages to offline users and forwards them to a component. The component stores them to database. This is to avoid DB access in plugin to make sure whole SM processing is fast.

Added by Gabriel Rossetti over 4 years ago

Artur Hefczyc wrote:

Gabriel Rossetti wrote:

Hmmm, is a plugin more like a hook, where you can do processing on a msg (for example an archive plugin could send all incomming msgs to an external database) or embellish a msg, etc?

This is correct. Pausing are generally responsible for handling a specific protocol, protocol parts or protocol extension - roster handling, presence, message, vcard, privacy lists, .....

If this is the case then the roster is a component and not a plugin, is that correct?

I do not understand the sentence above, roster protocol is handled by a plugin in Tigase.

But the offline message store could be a plugin?

This is actually realized by a plugin and a component. The plugin intercepts messages to offline users and forwards them to a component. The component stores them to database. This is to avoid DB access in plugin to make sure whole SM processing is fast.

Thanks.

    (1-6/6)