As you say, seems irrelvant at the moment and would probably be fairly trivial to implement later.. Of course it would rely on LFSW knowing about the tracks (i.e. 3rd party tracks being "registered").

My 2 pence is as follows: Whilst it's a nice idea it might also lead on to people relying on that to convert into a sensible track name, which could cause extra load and transfer at the LFSW end (given how I've seen some implementations of pubstat tools this could be extremely likely).

Quote from the_angry_angel :

As you say, seems irrelvant at the moment and would probably be fairly trivial to implement later.. Of course it would rely on LFSW knowing about the tracks (i.e. 3rd party tracks being "registered").

My 2 pence is as follows: Whilst it's a nice idea it might also lead on to people relying on that to convert into a sensible track name, which could cause extra load and transfer at the LFSW end (given how I've seen some implementations of pubstat tools this could be extremely likely).

You could force compression on the client side ... (that would increase load, but decrease bandwidth) ... or otherwise make the format for each of these more efficient some how. Callback functions on the side of LFSWorld to compress on the fly one time, and then serve the compressed 'static' file to all that query. The best peace of code is the code you don't have to make, in lou of that, the code that is made to run the least.

k i'll treat it as a whole separate thing and make a new action for it that simply outputs someone's total fuel stats.
I suppose i could make multiple output types for it as done with the teams action.

fuel stats btw are collected by keeping track of someone's driven distance and fuel usage per trackconfig / car. These stats are cumulative, so they average out over time. That means that fuel stats will vary a lot in the beginning and then flatten out. Changes in setup / economy therefore have little direct effect in someone's fuel usage stats. On that note i think i have to make fuel stats deletion features on lfsw.

But yeah, one could grab fuel stats from someone every once in a while - it's very cachable.

Forget about JSON, they can do that client side (if it's really wanted, I will implement it on the LFSWorldSDK.)

In the Dygear data struct for PB it is not space for the timestamp.
I think the timestamp (how old is the record) is a cool data.
And this data could be great to know in HLs too.


(same for HLs)
Timestamp as Unix time in an specific timezone (CEST?).

BTW: The fuel stats could be great to know from LFSW aswell but not really needed.

Rest of seggested structs are ok (country codes and TeamID).

Quote from Dygear :

Forget about JSON, they can do that client side (if it's really wanted, I will implement it on the LFSWorldSDK.)

Recebing responses from LFSW pubstats in a standard serializing method will clearify a lot the client side code.

What about PHP serialize/unserialize?
Tha arrays struct could be the LFSWorldSDK is using now.

Quote from kanutron :

Recebing responses from LFSW pubstats in a standard serializing method

There is no standard serialisation method across all languages though

Unless I'm missing the point?

Quote from the_angry_angel :

There is no standard serialisation method across all languages though

You're right. :P

I mean "popular" or "easy to port", like JSON, that can be used in (almost) all languages or PHP serialize/unserialize that can be used in ASP too.

Providing an optional argument to serializing method would be great.

c=0|1|2|3 < for compression method
s=0|1|2|... < for serializing method

While 0 = the current way (text), 1 can be JSON and 2 PHPserialize and so on.

Quote from kanutron :

While 0 = the current way (text), 1 can be JSON and 2 PHPserialize and so on.

I like the idea, if we could at all get rid of the LFSWorldSDK then I am all for it!
(The best code, is no code at all!)

Quote from kanutron :

Timestamp as Unix time in an specific timezone (CEST?).

One option would be for LFSWorld to look at the profile of the user and see what time zone they are in. But I think it should default to UTC. And I missed the timestamp option, it's a good idea!

unix timestamps are always in UTC. Your OS will calculate your local time for you.

i'm considering the selectable output type atm, but have a question :

Would it be preferred to use associative arrays or just regular arrays?
With the first, you'd get the variable names along with the data, making it easy to see what's what, but it will be less optimised than the second.

I suppose it should be the second, forcing ppl to code in a bit more optimised fashion

i'm currently preparing for 4 output types btw :

0) normal, plain text, or in some cases binary - this is the output as it's now.
1) JSON
2) PHP Serialized
3) XML

The three new types have their variables in the same order as with 0) once decoded. Just my question from previous post remains whether to use associative or regular arrays.

oh and if there are requests for additional output types, let me know.

Quote from Victor :

Just my question from previous post remains whether to use associative or regular arrays.

If you're going down the PHP route, you're probably not bothered about performance that much, and more concerned about simplicity. For that reason alone I'd go for associative arrays.

i was more thinking about saving a lot of unnecessary characters (transfer) actually.

edit - but yeah, let's keep it user friendly

ok got a 1.4 test url up for those who want to give it a try :

http://www.lfsworld.net/pubsta ... p?version=1.4&action=

(notice the different php file name - it's not the normal one)

Find attached the updated docs.

Let me know if there's something missing, not working properly, etc.

Quote from Victor :

i was more thinking about saving a lot of unnecessary characters (transfer) actually.

You could enforce gzipping on the heavier outputs - xml, json spring to mind particularly

I will try to give the test pubstats a thrashing tomorrow

Edit: Not had a chance to play with it yet. Currently playing restore monkey to a server, after a raid array died

Quote from the_angry_angel :

You could enforce gzipping on the heavier outputs - xml, json spring to mind particularly

+1
And +1 too for associative arrays.

Quote from the_angry_angel :

I will try to give the test pubstats a thrashing tomorrow

Lot of work today, but I'll try to test it really soon.

Thanks a lot!

Awesome!

I've been using 1.4 for the past couple of days now without any problems The extra information from the pb action is fantastic When is it going live?

I think it can go live any time.
There's just one thingy i'm not sure about. It's concerning the XML output and urlencoding. I urlencode text and binary XML data because htmlspecialchars or htmlentities doesn't apply to certain (binary) characters. Like null is left alone, but urlencode does convert any 'irregular' characters.
What I don't know is if values inside XML tags actually have to be encoded or not (apart from the usual < and &rt; and such.). Can I just put binary data in between xml tags, or should everything be urlencoded like it's at the moment? Or should i avoid having binary data in XML at all?

eg. TMLT values in the hostlist

Know you this?
http://www.w3schools.com/xml/xml_cdata.asp

Put everything between CDATA tags could be the solution.
But just urlencoding the data seems ok.

EDIT: I think that the usual way to put binary data into a XML is to encode in base64. But not shure.

With XML there's basically 2 accepted ways of serving content;
1. CDATA (unparsed character data)
2. Escaping (similiar to htmlentities), although there isn't a wide range of characters supported like HTML (only 5 or so)

CDATA is the most sensible.. However, if you're serving it as XML why would there be binary data at all? Serving as XML should negate this and provide a more friendly interface, so that you dont have to do bitwise operations! I'm talking about using attributes, etc.

Edit: That'll teach me not to refresh

welll, ok i've done the following :

When outputting XML I'm breaking up TMLT and TCRM into smaller, readable bits. With those binary values gone, i can omit the urlencoding.
But now there's a new problem : some hosts contain odd characters. Like characters lower than 0x20. Basically these shouldn't be possible to type in LFS imo, but alas, they are there nevertheless. And these characters give XML parsing problems.
Wrapping hostnames in CDATA doesn't seem to help.

Shall I just filter every character below 0x20 in hostnames? They're useless anyway and probably just a trick to get on top of a sorted hostlist.

Dont realy know much about this stuff but, if 2 host names are the same except for this character wouldnt that return 2 hosts with the same name? Very unlikly i know but still possible?


ps. Thanks for the AutoX help Victor

umm yes, seem theoretically possible.

i think i'll urlencode those chars < 0x20 and then that should be done with