A Skeleton XMPP 'Component Bot' that Executes/Responds to Commands

IN PROGRESS
Bids
2
Avg Bid (USD)
$191
Project Budget (USD)
$30 - $5000

Project Description:
The goal of this project is to create a very simple XMPP bot that will be used as an XMPP external server component (also known as a 'Component Bot').

The bot will be written in Python (unless we agree on a different language based on your suggestions, if you think another language would be better).

This bot is to be used to provide a service to XMPP clients also connected to the server that the bot will be an external component of (that is, not tied to a specific implementation).

You will require an understanding of Python, and some experience with the XMPP protocol and XMPP server configuration (ejabberd/Tigase) would be desirable.

## Deliverables

In the agreed language, you will create a bot that can connect to an XMPP server as a 'server component' to accept and respond to commands from other XMPP entities connected to the server.



The bot will be an external server component, that is, not tied to the internals of a particular server. The reasons it will be a component are scalability concerns that have been widely detailed (see http://metajack.wordpress.com/2008/08/04/thoughts-on-scalable-xmpp-bots/, http://metajack.im/2008/09/03/twitters-failures-are-not-xmpps-failures/, http://www.process-one.net/en/blogs/article/scalable_xmpp_bots_with_erlang_and_exmpp_part_ii and so on for more information).

The bot must be implemented so that XML stanzas describing new commands can easily be added in the future. It should handle connection and authentication with the XMPP server, and include a few test-cases of example commands. These commands should both demonstrate that the bot works in receiving and responding to the commands of the client, and also demonstrate how other, new commands could be added later. Some specific test cases are suggested in the 'Command Test Cases' section below.

If it is needed to demonstrate these features, a very small python client should be created that generates these commands, and sends them addressed to the server component.

For testing purposes, the server component should be tested using an ejabberd server and a Tigase server, since these servers both support component connections. Any configuration data needed to set these connections up should be delivered along with the completed bot source code.

A few protocols for components to connect to servers have been developed. The two that I know of are XEP-0114 ('Jabber Component Protocol,' described at http://xmpp.org/extensions/xep-0114.html) and XEP-0225 ('Component Connections,' described at http://xmpp.org/extensions/xep-0225.html). The bot will connect to the server using a protocol that works across at least these two implementations (ejabberd and Tigase). It may be one of these two protocols, but you may suggest another if you think it would be better.

The security of the connection should be considered in choosing the protocol used to connect and send messages between the external component and the server. As long as it works across both implementations, and doesn't compromise speed too much, greater security is preferable. The initial time needed to connect to the server doesn't matter, the speed of transferring and receiving messages to and from the server and clients does matter.

##############################################################################

Command Format

You are to decide on the appropriate protocol to use for sending commands and responses between the component bot and other clients connected to the server.

Interoperability is a goal in considering which protocol to use. I have heard that SOAP-over-XMPP has not received broad adoption. Please make recommendations for what would be suitable.

The protocol should be capable of sending fairly arbitrary, structured data, such as any XML content. It will not be necessary to transfer binary data.

##############################################################################

Deliverables

- A 'component bot,' written in the agreed to language, that connects to an XMPP server as an XMPP entity, and is then available to execute and respond to commands from other clients connected to the server.
- The component should handle connections through both a direct connection to the internet or through a proxy.
- It should read from a configuration file when it starts, that specifies the server to connect to, any data needed to describe itself as a component to the server, and any proxy settings (if they are used).
- Authentication data should be requested when the component starts up, especially passwords (a username/identifier could be stored in a configuration file, though), to reduce access to this information.

- A very small XMPP client used for testing a few command test cases implemented by the bot, as documented in the section 'Command Test Cases.'
- The client is only intended for testing the commands, it does not need to provide a chat feature.
- It can be extremely simple. Unless it's required for your testing, you don't need to include the ability to connect to the server through a proxy.

- Any configuration data/scripts needed to get the test client working.

- Any server configuration data/scripts needed to get the component bot working with ejabberd and/or Tigase.

##############################################################################

Command Test Cases

- Time of day

The server will respond to this command (with no arguments) from the client by sending it the current time of day in the server's local time zone.

It should return hours, minutes, seconds, and milliseconds.

- A stack interface, with push, pop, top, and stackSize commands

push

The client can send a push command with a string argument, and the component will push the string on to it's stored stack of strings

pop

The client can send a pop command, with no arguments, and the component will pop the top string off it's stored stack. No value will be returned.

top

The client can send a top command, with no arguments, and the component will reply with the string at the top of its stored stack. When the client receives the reply, it can simply print the returned string. If the server's stored stack is empty, the server should respond with a value to indicate this.

stackSize
The client can send a stackSize command to request that the server respond with the number of strings currently on its stack. The returned value must be positive.

- A command to calculate the distance between two 2D points

The client can send two (x,y) tuples, where x and y will be real numbers, and the component will send a real value that gives the distance between the two points, calculated as follows (where (x1, y1) is the first point, and (x2, y2) is the second point):

sqrt((x2 - x1)^2 + (y2 - y1)^2)

When the client receives the response, it can just print it out.

Those are all the commands that should be necessary to demonstrate that the component bot works when delivered, and suggest how to extend it in the future.

Skills required:
Amazon Web Services, Engineering, Java, Linux, Mac OS, Microsoft, PHP, Project Management, Python, Script Install, Shell Script, Software Architecture, Software Testing, Windows Desktop
Hire tropicalpenguin
Project posted by:
tropicalpenguin New Zealand
Verified
Public Clarification Board
Bids are hidden by the project creator. Log in as the employer to view bids or to bid on this project.
You will not be able to bid on this project if you are not qualified in one of the job categories. To see your qualifications click here.


Hire mlys
$ 339.15
in 14 days
Hire nicKTime
$ 42.5
in 14 days