SDK v0.2

[gouxim]

Just to keep you guys posted about a new release.
Check the main SDK topic for changelog and download link.

[Jojo_44]

Hi,

I hope it´s ok to post here. With this SDK you can access the user data without the access of the user. But what about player home where you must give the access ? Where is the context ?

Another thing is if it is possible to become a function where I can get the current server of a player. Maybe with the access of the user. So we can display it in a forum for example and other forum visitors can join your server and playing with you.

best regards,

Jojo

[TheM]

Hi,

I hope it´s ok to post here. With this SDK you can access the user data without the access of the user. But what about player home where you must give the access ? Where is the context ?

As far as I understand your post... the user data in this SDK were already available in the old statsserver thingie (except for the isOnline thing)? So I don't see the problem ...

Another thing is if it is possible to become a function where I can get the current server of a player. Maybe with the access of the user. So we can display it in a forum for example and other forum visitors can join your server and playing with you.

An extra return called onServer (or something like that) giving the serverlogin would be great indeed!

[Jojo_44]

As far as I understand your post... the user data in this SDK were already available in the old statsserver thingie (except for the isOnline thing)? So I don't see the problem ...

If you open http://developers.trackmania.com/ for the first time, you will be asked if you grant access to your account. Also the same thing here in the forum. Before your nickname, zone, and mp rank was shown you had to grant access to http://forum.maniaplanet.com. You see your linked websites at http://home.trackmania.com. And with this sdk you don´t have to agree. Thats what I mean.

regards, Jojo

[gouxim]

This API is only for retrieving "public" information, just like the old stats server as The M pointed out. It provides no auth or access to private data such as buddies. (I might have to double check for the online status if we want it to be public or not).

The scenario on the forum plugin and the playerhome is different: the user logs in so it acts as an auth system (like facebook connect) so you are sure that the current player is actually himself ; then you can access private data from a 3rd party auth.

It's on our plan to release that feature to the community ; we'll probably implement the OAuth2 protocol, which simple yet powerful. It the same technology used on Facebook's, Twitter's and Google's API for instance. When we implement that feature you'll be able to allow a user to "connect" on your site using his trackmania account and give your app permission to access its private data. If you want to get a glimpse of how it works you can check the very good google documentation of their oauth2 implementation : http://code.google.com/apis/accounts/docs/OAuth2.html

As for the "current server" information, for now we are testing some basic web services, but we will obviously expand the api and add more services with more information...

[Jojo_44]

Ok thank you for the detailed answer. I have another question concerning the speed. If I open a thread here on maniaplanet where users have added here nickname, zone and ladderrank is the speed just the same as without. If I do this on my site, I have a loading time of > 1 second for 5 players and with additional data like tags, isOnline, ladderpoints I have a loading time of > 2 seconds. Is this normal ? Maybe you want to have a look:

http://upload.zero-esports.org/tmws

The rest looks fine, no problems yet.

regards, Jojo

[gouxim]

Yes use the same API.

HTTP requests cost a lot in terme of execution time. It's kind of OK from the server that hosts the Maniaplanet Forum because it's on the same cluster that the API so the network latency is almost 0. But from a server away from the API, it can add up pretty fast and you get slow loading times.

The typical solution is to cache the API results (in a file, in a database, in APC, in Memcached etc.). Caching is a powerful yet simple solution that we use pretty much everywhere in our infrastructure.

[Jojo_44]

If you say http requests cost a lot of time, I would say that it must be possible to get multiple player data with one request. Like this:

Code: Select all

$isOnline = $tmPlayers->isOnline($login1, $login2, $login3, ...);

This would increase the speed for multiple data, or i´m wrong ?

best regards, Jojo

[m4rcel]

To think a bit further:

I think the non-plus-ultra would be, to be able to "stack" several (also different) requests, and to have them executed all with a single call to the API.
Maybe a little code example will help understanding my idea:

Code: Select all

// Begin adding multiple requests, without having them executed now.
$tmfPlayer->get('m4rcel');
$tmfPlayer->get('gou1');
$tmfPlayer->isOnline('m4rcel');
// etc.

// At the end, we let them execute all with one request to the API
$response = $tmfPlayer->execute();
// $response will hold information about m4rcel and gou1, and the online state of m4rcel

Advantages:
* If you already know, what you want to call next, one single request will be enough to get any data you need. This may save a lot of time, as there is only one Connection-Establishment, and one Response from the Nadeo-Server.

Disadvantages:
* The API would getting more complex on Nadeo's side, as it ave to be able to handle several requests at once -- Not possible with the current URL-like calls.
[Maybe it is possible to introduce a new mthod like "multirequest" using POST, where as content you have one request on each new line so that the Server knows which requests he has to execute... I dunno ^^]
* The response would get more complex: Instead of having a single object returned, you would have an array of objects, one for each request. It would be mostly the programmer's task to remember, which item of the array will be the response of which request.
[Back to the example above it would mean, that $response[0] holds the data of m4rcel, $response[1] those of gou1 and $response[2] the online state.]


These are only some thoughts which came to my mind -- Maybe they help you finding some better ideas :p

Coming back to Jojo's post, I also think it is important to at least combine multiple online-requests, as those data will mostly be invalid when called the next time (whereas such like Nick and Zone won't change that fast, I think...)

[farfa]

It's not possible to stack request with the REST architecture, I really recommend you to read the documentation about the REST architecture (Wikipedia, First article about REST).
The request are not like SOAP, but more like a web page. Imagine you are request 5 web pages at the same time for the same window, and it will be a big mess.