REST XMPP Gateway

Cancelado Postado Nov 11, 2010 Pago na entrega
Cancelado Pago na entrega

You must write a PHP RESTful gateway to XMPP that exposes three endpoints: [url removed, login to view], [url removed, login to view] and status.php. It needs be able to communicate with users on networks added through XMPP’s XEP-0030 Service Discovery extension, as well as accepting/subscribing to/authenticating them if necessary, although it should ignore any new add requests.

I have Ejabberd set up with Spectrum ([url removed, login to view]), which provides a gateway to MSN, Yahoo, Facebook, Myspace, AIM, Google Talk, Jabber, ICQ, GG, and QQ. It must work with all of these with the only intervention being login details for the networks saved in their Spectrum MySQL databases.

These are the endpoints required:

/[url removed, login to view] - with the parameters “text”, and “to” which posts a message to someone.

“to” is a UID in the format “network:id”, unless the id contradicts the main user id on that network or is random. E.g. for Facebook, the ids in the chat API don’t match the ids within the rest of the API, so the UID should be in the format “facebook:chat:id”. Calling [url removed, login to view] removes the “typing” status from whoever the message is to.

/[url removed, login to view] - which doesn’t return till it has something to report or 30 seconds has elapsed, whichever is sooner. It gets any new messages or status notifications (online, offline, away, typing, as well as add, remove and modify to update the friend list, and self if seq=0 to inform the client of its details) to deliver to the client, and outputs in the following format, without whitespace:

See [url removed, login to view]

or {"nextseq":3} if there is nothing to report.

It is called with the parameter “seq” which increments each time something is returned. Each time something is returned it is cached in Redis under the key “chat:uid” (see below) with a ttl of 7 days, with each response linked to the “seq” number, so that if a request is made with that “seq” number again it returns the linked response and all responses after it, collated, with all redundant information removed and the next “seq” to request in the “nextseq” element. When the “chat:uid” record is saved all messages older than 7 days should be deleted.

It needs to get details from vCards, including at least name, firstname, username, displayname, the URL of any profile pictures (which should be saved to a local directory with the URL in the user object returned by [url removed, login to view] being in the format “http://xxx/img/[url removed, login to view]”). If any details are missing guess them. The script must also serve a vCard with these details.

Also note that multiple instances of the script could be running for the same user, so if one instance of [url removed, login to view] returns a response to a request with a “seq” of, say, 7, then all other instances of the script running for the same user id must return the same response for that “seq”

[url removed, login to view] also needs to return messages posted by the active user, with the "user" being "self" and the user it was to in an added "to" field.

If a user isn’t connected to [url removed, login to view] for 30 seconds then they should be signed out of XMPP and any services by a 4th, endlessly looping php file called [url removed, login to view]

/[url removed, login to view] - which allows the client to update their status with the following POST parameters:

status=typing/nottyping&to=uid to add/remove the “typing” status to/from the “to” user, using XEP-0085. Someone’s status is only reported as “typing” by [url removed, login to view] if they are typing to you

status=away/online

The XMPP login details should be at the top of the files, as well as the user id used in the Redis key “chat:uid”, and the “self” object returned by [url removed, login to view] when seq=0 and used for the "self" vCard. Bear in mind when the script is used these details will be different each time. It must not be object-orientated, must be well-written and very performant. No documentation is required.

I said it should use Redis, but if you think anything else is more suitable then you can use that after running it by me.

If anything’s unclear please let me know.

For an example sequence see [url removed, login to view]

PHP

ID do Projeto: #851132

Sobre o projeto

2 propostas Projeto remoto Ativo em Dec 8, 2010

2 freelancers estão ofertando em média $550 nesse trabalho

jobBoys

hello sir i hope i can helping you, please check your PMB,thanks

$500 USD in 7 dias
(2 Comentários)
3.0
ixwarrior

Hi, I have written an XMPP library that basically has the same functionality. It was designed to talk to Jabberd and a proprietary XMPP based server. With some additions (e.g. support for TLS, other events, etc), it Mais

$600 USD in 10 dias
(2 Comentários)
2.8