IB Shout | IB Shout History | IB Shout Statistics

Yeah, that about sums up the differences. I suppose there are a few more finer points, but those seem to be the key ones. Lower case HTML tags mostly, and being less forgiving about closing of tags. It's essntially a "cleaned up" form of HTML, and is supposed to have less incompatible browser quirk issues. It also compresses better, since most page content has more lower case characters than upper case characters, so there is more redundancy between the page content and the markup tags. (Unless it's an AOL page...? ). That and it's easier to type lower case tags.

There is an XHTML validator you can use to check your sites: http://validator.w3.org/

I generally prefer XHTML over HTML, mostly because it seems to be the strictest set of rules, which usually means what you write is pretty much guaranteed to work anywhere. Although, it's not technically a strict subset of HTML. For example, one difference I've come across is that "<BR>" is valid in HTML, whereas "<br />" is valid in XHTML, and each are invalid in the other format. Basically, XHTML forces you to close every tag, including ones that are always empty (usually with the shorter <tag /> syntax, instead of the longer <tag></tag> syntax). HTML tends to ommit certain end tags when the tag never has any content. Oddly enough though, script tags still need to be given as <script></script> pairs, even if they're just referencing an external JavaScript file. It won't work if you try to use <script /> syntax.


Btw, as for various web languages, here's how their purpose breaks down:
Client Side (parsed/used/executed by the browser):
1) Content and Structure: HTML, XHTML
2) Layout and Appearance: CSS
3) Behavior: JavaScript

Server Side (parsed/used/executed by the web server):
1) Flat files simply served as is: .html (HTML/XHTML), .css, .js
2) Executed, and standard output returned (usually the output is an HTML/XHTML page, but it could be an image, or any other file type):
PHP, Ruby, ASP, Perl, Python, ... pretty much anything you want to use really, including compiled binaries.
2a) Run as a CGI script (like starting a new program, and loading it from disk for each GET request, which can be a little slow). Any language can basically be run this way, usually scripting languages, sometimes compiled binaries. Since the process is isolated from the web server, it won't bring the web server down if it crashes.
2b) Run as an Apache (or other web server) module. These get loaded by the web server when it's started and stay in memory, so they should provide lower latency responses. If the module contains a bug which could cause it to crash, it can bring down the whole web server. PHP is typically run as a module. Note that the previous comment means a bug in the PHP interpreter, not in the PHP script. The PHP interpreter should handle problems with the PHP script by basically terminating the script, without crashing the interpreter, or Apache. Ruby also has a module, although, the use of mod_ruby is somewhat questionable, mainly due to a single shared interpreter instance, and caching of required files, so they won't pick up changes unless you restart the web server. There are other Ruby modules I've heard of but they seem to basically use...
2c) Run as a seperate private internal web server, to which Apache makes proxy requests. To the client, it appears these requests are served directly by the main web server (usually Apache), but are actually served by a more custom built framework, which is usually tied to a specific language. For example, Ruby on Rails seems to use this approach. This would appear to have many of the same performance benefits as an Apache module, but perhaps with a bit of extra latency due to the proxing. Also, flaws in the secondary web server are isolated from the main web server, so if it crashes, it won't bring down the whole web server. It may however bring down that one app. I've heard in the case of a mod_rails though, that it may actually restart any failed secondary servers upon the next request that Apache gets.


I doubt I'd get after anyone for not doing work. It's not like I have time to get a whole lot done anymore. Heck, I probably don't even have the time to chase after other people to get things done. My intention is that it will be a purely voluntary basis. I would expect people to just work on what interests them, and if something gets done and is reasonably polished, they can post an announcement or send a PM, so it can be reviewed and put up on the site.

This post has been edited by Hooman on Nov 24 2009, 10:48 PM

If it can wait a few more weeks, I'd be happy to help. I have 1 more week of instruction and finals week after this week is over (yay for thanksgiving break!)

this is the point of using the logs from the bot it makes the same thing as the shout box viewing the log of like the last 5 or 6 lines said. you would see what was said last. But making it IRC also mean if there are 2 or more of you guys on the forums at once then you could have the live chat.

logs is what kills it. People are lazy by nature, and we don't like having to do more work to see the same thing.

To get the desired effect of the topic thats what would happen.

The whole point of this is to make it so the lazy people can stay lazy and be on irc at the same time and maybe they will enjoy the community a little more because they might get a live chat in here and there. It also might spark a interest in playing the game again.


offtopic moved hehe please continue
http://forum.outpostuniverse.net/index.php?showtopic=4716

This post has been edited by Freeza-CII on Nov 27 2009, 09:40 AM