Implementing a Protocol

What you need to do in the slick (Service Leveraging Implementation Compatibility Kit) is make sure that when using your implementation as an OSGi service (i.e. by only referring to it through the service.* interfaces) all features works as expected. You could do this one of two ways.

• Create an account with your implementation on one side and make it communicate with some (very limited) protocol implementation that you provide in the slick itself. This is the way we do the testing in the ICQ SLICK. We have a class called IcqTesterAgent and we use this class to send and receive hardcoded messages to and from the service implementation. We would also change the tester agent’s status and make sure that the service implementation has seen this status change and vice versa (i.e. change the status of the service implementation and make the tester agent query the ICQ server making sure that a status change has indeed taken place).

the other way to do such testing would be to:

• Create 2 accounts of your service implementation and make them communicate with one another (that’s what we use when testing our SIP protocol provider). This approach is similar to the first one with the difference that instead of having a protocol specific tester agent, we instantiate the PP service a second time. The disadvantage here is that while you make sure that the various methods work, you have no guarantee whether they respect the protocol they claim to implement. The advantage is the fact that you could easily reuse SLICK code for various protocol implementations (we are event thinking of using such an approach in order to implement a generic protocol provider slick that would support all protocols.)

For most protocols, going online requires some sort of user credentials (a password, an MSN passport or other). By convention we store such material in the

 lib/accounts.properties 

file of the project. You won’t have this file after a clean checkout as it is supposed to contain information that is both sensitive and specific for your own sandbox (i.e. you can’t expect all project members to log on say ICQ using the same account as most of them would be rejected after the first one has logged in). In order to create this file, you can use the

 lib/accounts.properties.template 

file and add you own account information inside it. When adding a SLICK for a new protocol, simply add the properties you need inside the accounts.properties.template without setting values for them and then copy and init them inside your own accounts.properties file.

The SLICK package for the Gibberish protocol is available here.