PROTEJA QUEM VOCE AMA! LEMBRE-SE MOTO NAO TEM PARACHOQUE! SE BEBER, PEGUE UM TAXI! LUTE PELA VIDA:PRATIQUE DIRECAO DEFENSIVA!NAO BRIGUE NO TRANSITO. What I'm doing right now? Finishing some details, like documentation and tests improvement, also, one more feature is being planned to be added, that is a RSM like URL query, this means: GET /channel@domain.com/media?max=10&after=fooWill return the first 10 metadata info (ordered by last modified date) after the media with id equals to foo.Next monday (13th), is the suggested pencils down from GSoC 2012. It was a pleasure to work with the buddycloud team, and I've learned A LOT during this period. Finished the XEP-0070 implementation, the Media Server was ready to be deployed, and yesterday the first tests with Denis' HTTP API + Media Server were excellent! Some bugs, of course, but already fixed, and we are very excited with the result of our efforts.Although, there are some improvements needed by the Media Server for the next couple of weeks:- Handle video media previews;- Handle clients with bare JIDs: the XEP-0070 negotiation with those clients needs to be done via XMPP messages;- Handle audio media: set length property;- Documentation. This blog has been moved to http://rodrigods.com. The main module from the Media Server is its XMPP component, it has several responsibilities, including the authentication process.The authentication process that will be used is based on the XEP-0070, to illustrate how it would work, here is a sequence diagram:As described on XEP-0070, the Media Server will provide two types of HTTP authentication, Basic and Digest, both requests user's login and password as authentication mechanism, in this way, the Media Server has to have a mechanism where it will verify the passed password.The authentication response and authorization request are already implemented, the next steps are implement the verify password mechanism and request confirmation process.edit: changed the sequence diagram after discussed some points with Kev. It's great to see the two buddycloud's GSoC projects working together. Denis has built a toy client to demonstrate his HTTP API, and this week he adapted it to handle channels avatars provided by the Media Server. Here are some examples:https://www.denisw.de/buddycloud-http-client/https://www.denisw.de/buddycloud-http-client/?channel=team@topics.buddycloud.orgAlso, there are some examples of already stored media:video: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/Jw8Eq6kWf6m2rmAg0Nrpvideo thumbnail: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/Jw8Eq6kWf6m2rmAg0Nrp?maxheight=150image: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/avatarimage thumbnail: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org/avatar?maxheight=200media list from a channel: https://api.buddycloud.org/media/gsoc2012@topics.buddycloud.org One useful type of URL query are paging queries, they limit the returned data into a specified range so, since the amount of displayed items are lower, the interface performance is improved.Since we are implementing a XMPP media server, would be great to have something similar to RSM (XMPP way to do pagination), at least, similar to its syntax. So, the implemented paging for the media server is like: GET /channel@domain.com/media?max=10 -> returns max 10 metadata media info GET /channel@domain.com/media?max=10&after=foo -> returns max 10 metadata media info after the media with id equals to fooThere are no new features to be implemented, so the effort in this final week is to polish the code and improve documentation. During the last two weeks, we decide to do some changes at the URLs definitions and the stored metadata of each media.Now,