Is there a way to put Dustin is online at xxxxxx, on a webpage that has html?

Thanks in advance,
-Dustin

HTML, no, closest you'd get is the recent LFS online images and display them. That would specify if you were online/offline/pits/spec but not say where.

PHP/ASP and prolly most forms of web programming documents could display this info for you though.

http://www.mercuryracingteam.com/whos_online.php

Currently gives a f**ked up server name cos of colour coding however thats no longer an issue ive fixed it just need to move our website to its future home.

i dont know if javascript or something like that could call the php script (or whatever language) INTO the html file, but really html is a dumb language, not an intellegent one, it doesnt think it just does what its told (unless viewed in IE )

As paul said HTML very basic...this is a good link to learn about HTML basics http://philip.greenspun.com/panda/html

I know html very well, I was just curious to see if there was an online at yada yada, Like behind the fences (I forget the website). They have it telling if they are hosting an online server. hmm :O

The new status buttons can be used with just HTML, more info could be served using dynamically created javascripts with document.write()'s, new feature for LFS World perhaps? (i think Victor likes javascripts )

Theoretically you could do it with a JS implementation of an LFSWorld parser, but it would be slow, error prone and likely very very nasty. In addition, caching would be difficult, if not impossible so if you got any concurrent requests to you page, someone is going to have to wait for the tarpit to expire.

JS aggregation or pretty much any remote scripting technique that requests remote data from a backend script / program would be better.
The HTML page would have JS that requests a page on ServerX.
ServerX would have a publically accessible page that takes the racer name and maybe some other options as parameters, queries LFSWorld and then displays data that is easily parsable by JS (JSON for example).
The JS on the requesting server would then decode the data, and you could use at will...

There are loads of web pages documenting remote scripiting that'll let you get around any browser sandbox issues, but it would still require a script / program somewhere to convert the LFSWorld request in to JS parsable data.

Of course, you'll need full source access for either approach, so posting your status on other sites that you do not have source access to would not be possible unless they allowed remote scripting (which none do intentionally becuase of the security risk).

Well that's about a million times more complicated than what i meant/had in mind.

What i meant was ..


Service provider would probably be using a local cache of the hostlist.

Quote from filur :

Well that's about a million times more complicated than what i meant/had in mind.

What i meant was ..

<script src="http://example.com/host.php?MyServername"></script>
<script src="http://example.com/online.php?users=username,username,username&template=vertical2"></script>

document.write('MyServername, Aston North (12/23)');
document.write('username is offline');

Service provider would probably be using a local cache of the hostlist.

That would be JS aggregation
The snippet of the script srcs would be the HTML page.
http://example.com/host.php & http://example.com/online.php being the scripts on ServerX that make the LFSWorld request and turn it in to something easy for JS to parse... or in your case display it directly.

I think it would be better to just give it back in a var though than display it, or like I said before use JSON. The advantage to the latter would be that you could use multiple remote scripting techniques to fetch it, therefore it is more flexible, and since more than one language has JSON encoders & decoders, you aren't just restricting clients of the backend script to JS.

The reason for the var or JSON over displaying it is fairly obvious I think; it lets the user do more with it, or use it more than once without making multiple requests.

Quote from Anarchi-H :

That would be JS aggregation

:shhh:

Quote from Anarchi-H :

I think it would be better to just give it back in a var though than display it, or like I said before use JSON. The advantage to the latter would be that you could use multiple remote scripting techniques to fetch it

I think i'd stick to extremely simple stuff for JS, code generator style, click button, copy, paste, stuff appears on website. XML for anything else.

Quote from filur :

Well that's about a million times more complicated than what i meant/had in mind.

What i meant was ..

<script src="http://example.com/host.php?MyServername"></script>
<script src="http://example.com/online.php?users=username,username,username&template=vertical2"></script>

document.write('MyServername, Aston North (12/23)');
document.write('username is offline');

Service provider would probably be using a local cache of the hostlist.

so if i put that in my website will it show up :X Sorry, im a noob :dnfnoob:

Quote from imthebestracerthereis :

so if i put that in my website will it show up :X Sorry, im a noob :dnfnoob:

That stuff was just an idea, needs someone to create and serve it. Would probably need to be lfsworld since pubstats is sort of a semi-non-free service now, would be a bit weird if someone else offered a mirror of practically everything for free.

like this http://www.racing-radio.co.uk/ under server info

Quote from filur :

I think i'd stick to extremely simple stuff for JS, code generator style, click button, copy, paste, stuff appears on website. XML for anything else.

You could easily do copy n paste stuff for JSON, only in this scenario, someone who knows a bit of JS could easily adapt you stuff to what they need. If you are just going to display it, you are making things harder to adapt.


Anyway, the reason for JSON over XML would be higher data to markup ratio. LFSWorld data is lots of little chunks of data which XML puts a huge overhead on (when someone suggested XML for the LFSWorld sources, I think I did a quick test and came up at 7 or 800% overhead for an average host list at the time).

I may mock up a quick demo script of this because it has a plethora of uses, and the more I think about it, the more it makes sense.

(filur: You aren't a Java programmer per chance are you? )

Quote from imthebestracerthereis :

like this http://www.racing-radio.co.uk/ under server info

Their data is generated by a server side script, which generates the output in html.

I don't think its been obviously mentioned, but are you aware of the difference between HTML and server side scripts which generate HTML? Basically HTML is static and can't do much. With Javascript you can do a few things, but its all done client side. Using something like PHP, ASP, JSP, etc. you can manipulate data on the server to present things like that.

As Anarchi and filur have stated its possible to "work around" this using javascript, but theres no third party "gateway" which allows this atm

Quote from Anarchi-H :

<script type="text/javascript" src="http://example.com/hosts.php"></script>
<script type="text/javascript">
<![CDATA[
var objHosts = strHostsList.parseJSON();
document.write(objHosts[0]['hostname'] + "<br />");
]]>
</script>

Please! No document.write! It doesn't work with certain document / mime types... surely using the DOM tree object(s) would make more sense?

Quote from Anarchi-H :

Anyway, the reason for JSON over XML would be higher data to markup ratio.

Or just binary ... It's a hell of a lot better for data to markup. (Yes there is SOME markup in binary, for example the fact the there is 24 chars and no matter what there is always going to be the 24 chars for that string.)

Quote from Dygear :

Or just binary ... It's a hell of a lot better for data to markup. (Yes there is SOME markup in binary, for example the fact the there is 24 chars and no matter what there is always going to be the 24 chars for that string.)

Thats not markup; the null bytes are just data!
In order for it to be markup, it has to have extraneous semantic, structural or presentation data in addition to the actual data (aka metadata).
Now if the length of that string was stored in a byte before the string or if there was a byte before the string that identified what was in the string (1=NAME, 2=USERNAME, 4=HOSTNAME, etc), then that could very loosely be called markup. (Albeit for a very specific data set)

Nit picking aside, text parsing is easier in JS than binary parsing is and you lose the whole 'JSON encoders & decoders already exist in about a million languages' advantage.

Quote from the_angry_angel :

Please! No document.write! It doesn't work with certain document / mime types... surely using the DOM tree object(s) would make more sense?

Yes it might but I couldn't be bothered to get my DOM for dummies book out to write the sample

Quote from Anarchi-H :

If you are just going to display it, you are making things harder to adapt.

But very simple to use (and present), if the JSON backend already existed that't be great, but i wouldn't write one for this purpose.

I can't see many people using the more advanced stuff (insert fancy terms of choice, im very tired. ).

Quote from Anarchi-H :

(filur: You aren't a Java programmer per chance are you? )

No.

uh, I think it would just be easier to link to my user cp and tell them to look at where i am :P I am only 14, I dont get all that conplex stuff real well

Quote from imthebestracerthereis :

uh, I think it would just be easier to link to my user cp and tell them to look at where i am :P I am only 14, I dont get all that conplex stuff real well

Lol, don't mind us, we just hijacked your thread

Quote from filur :

But very simple to use (and present), if the JSON backend already existed that't be great, but i wouldn't write one for this purpose.

I can't see many people using the more advanced stuff (insert fancy terms of choice, im very tired. ).

I could write the code the backend would require on a couple of sheets of toilet paper if I were to use LFSWorldSDK or PPF to parse the data.
Anyway, I think you've got your way and I've got mine. I doubt they are going to converge (do they ever? ) so I'd best just drop it...

Still might try it though

Quote from Anarchi-H :

I could write the code the backend would require on a couple of sheets of toilet paper if I were to use LFSWorldSDK or PPF to parse the data.
Anyway, I think you've got your way and I've got mine. I doubt they are going to converge (do they ever? ) so I'd best just drop it...

Still might try it though

I don't mean it's a bad idea or that it would take very long, just that i wouldn't use it for the thing i had in mind (and not really fit the target group of users [my target group, if i was to .. etc etc]).

The JSON provider would surely be a neat thing all by itself.

Quote from filur :

I don't mean it's a bad idea or that it would take very long, just that i wouldn't use it for the thing i had in mind (and not really fit the target group of users [my target group, if i was to .. etc etc]).

The JSON provider would surely be a neat thing all by itself.

Fair enough, I see your POV
From my POV a JSON provider would mean less focus on the implementation and more focus on the data and creative uses for it.

I think I'll check with Vic about redistribution first in case he has any issues with it. If not I'll front Scavier some cash for premium access and see if I can get something cooked up over christmas.

If you ever find/make a script for html just post it for me ... Continue with the hijacking :O

The huge plus with JSON is that it's javascript parseable, huge plus as you off load some of the work to the clients computer. But you would have to deal with people who have JavaScript turned off . . . Not such a big deal tho, it's only Steve Gibson that does that.

Quote from Dygear :

The huge plus with JSON is that it's javascript parseable, huge plus as you off load some of the work to the clients computer. But you would have to deal with people who have JavaScript turned off . . . Not such a big deal tho, it's only Steve Gibson that does that.

Gracefully degradable web content "ftw".

i.e. rebuild the DOM as the page loads using javascript, rather than expecting it to be on. This not only solves the "what if its off" problem, but also "what if its an older/unsupported browser"

Graceful degredation in the event of no JS support would be high on my priority list if I were to provide a usage sample for a JS implementation.
I browse with JS disabled by default and some sites just dont work without JS, sometimes for no good reason... which is annoying.

Take note Mr Dygear because SimFIA is one of them.