Reread what I wrote: "a decision can be made while messages are still incoming to stop storing the message". It can trivially be done with XMPP. Yes, you still need to push it through the parser to determine the message boundary, but you don't need to store the result until the message is complete - just shove it down the recipient socket as fast as it can take it.
I've implemented this approach for various protocols several times, and it does wonders for latency, and can save quite a bit of memory as well if messages are potentially large.
I just for my bare life can't see why you think it would be inelegant, more error prone or more work. Pseudocode to illustrate:
Main loop: while (not shutdown) { select(sockets) for (each socket that is readable) { read(socket, buffer, sizeof buffer); mySaxParser.parse(buffer) } ... handle pending writes... }
Start tag handler: openTags.push(); if (openTags.size() >= 1) pickDataToStoreForProcessing();
End tag handler: poppedTag = openTags.pop(); if (poppedTag != closed tag) error(); If (openTags.size() == 1) processMessage(...) (document tag for XMPP is the "stream" tag, which encloses all the messages, so 1 open tag means an enclosed message was just closed)
Care to explain how different framing would make the above so much better? You're stuck with an XML parser since the documents you are dealing with are XML anyway, so what little overhead you're dealing with in terms of matching up tags and checking for the end of a message is completely trivial compared to the amount of code handling the parsed data will take regardless of framing, and shouldn't even show up in profiling.
If storage and performance is really a concern, you might gain a tiny little bit by using an XML tokenization library directly instead, to make 100% sure there is no duplication of state, but most of the time there won't be any point.
Once you've done this kind of thing a couple of times, you'd write this kind of basic infrastructure in your sleep, or reuse a generic template.
It's also a structure that scales very well, because many operations can be started before a message is complete. For instance if you're routing messages you might start pushing them to the recipient as soon as you know where to send it, throwing away state as soon as it's been successfully written. The effect on latency can be quite dramatic for very little additional work.
I don't use Java unless I'm forced to:-) And I don't have any code that I could share without violating past employment contracts, no, but I can describe the approach - there's nothing novel in it, it is simply a combination of two techniques: 1) Doing buffered multiplexing IO by maintaining a buffer per connection and doing non blocking reads of as much data as possible in a single syscall and 2) throwing away redundant information during a parse to "compress" the read information to only what your application actually need. I don't even remember where I picked up these techniques - I consider them blindingly obvious, and it's how I've been writing networking code for the last ten years at least.
First of all, a long stream of Jabber messages is irrelevant - you won't be handling more than the greater of your IO buffer (and don't try to tell me 100MB would be a sensible size) or one XML stanza and parts of another at most - so unless you're leaking memory the length of the stream have absolutely no bearing. The IO buffer size is a tradeoff between performance and memory usage, but can be fairly large since in a multiplexed environment it will be shared between all the connections when you are parsing the message as you go.
If you want to parse the message at the end, however, you'd need to retain a copy of the message.
Second, a SAX parser needs to maintain only very limited state between calls - it needs the XML namespace declarations and a list of open tags, and enough space to hold a single incomplete token. I'm sure you can find implementations that keep all kinds of extra around, but I've both used and written parsers that have made do with just the above.
The general approach then is to maintain a fixed size IO buffer, fill it as much as possible with a single non blocking read (which btw. is another reason to consider interspersing processing with the reads, as you for some workloads otherwise end up context switching to fill up only small parts of the buffer at a time), feed it to the SAX parser. If any events are fired, your code looks at the data and throw away any parts it doesn't need, or stores it in whatever more compact form is convenient for you. If the message is complete, process whatever stored data you have gathered from it, and throw away afterwards. Repeat as long as the connection remains active.
Since XML usually is extremely redundant, it is normally trivial to come up with an internal representation that is more space efficient than raw XML, but many applications (including XMPP) don't even need all the data from many messages - often you only need to store parts of the data you are receiving. If space is really important for you, and you're dealing with limited XML vocabularies, this is particularly true, as "compressing" the XML can be very efficient.
Applying this to multiplexed IO is exactly the same as for the single connection case. You maintain the state required per socket. Each time the socket becomes readable, you fill the buffer as much as possible, and feed the SAX parser.
No, it's not guaranteed to always save space - if you NEED to do processing on the raw XML for whatever reason, or NEED all the data before you can do processing that allow you to throw some of it away (after passing it on to another client or server for instance), you could apply compression techniques to your IO buffer without parsing the XML and might end up doing better, but I've yet to come across a single real life application where that would have been a useful approach.
That said, I'd not usually spend time doing any of this except as a side effect of the convenience of storing the data in a more useful form than raw XML, as memory is cheap and developer time isn't. Given relative component costs it's almost always IO performance that is the most cost effective to optimize in the kind of systems I've dealt with.
I agree that useless context switches are painful, which is another good argument for not just fulfilling a read and immediately going to sleep again waiting for more IO when you have useful work you can do on the read data.
However reducing context switches is often quite straightforward. I'm shocked at how often I see network code where read() is called with ridiculously small buffers because people can't be bothered to maintain userspace buffers to do read()'s across frame boundaries in stream oriented applications and end up only read()'ing whatever amount of data they happen to know belongs to the current frame, for instance. Once an application is well structured with respect to use of system calls etc., I rarely see applications where context switches are much of an issue on a well tuned system.
You're right that the case I suggested in what you quoted above is unlikely to be a problem in many ordinary scenarios, but one case where it can be an issue is for instance if you're on the receiving end of massive mailing list blasts from badly set up mail servers (or spammers). Many other services that have potentially "hostily users" as clients have patterns where sudden surges of traffic may occur, and where there may be "considerable" (compared to the cost of parsing the message stream itself) costs to process the message.
For mail servers in particular, which are usually almost entirely dominated by disk IO (typical CPU usage on the MX's of a system I worked on connected to an IBM Enterprise Storage System was around 10-15%) being able to start filtering as soon as you've received the first byte of a message allow you to very quickly take actions to determine whether to keep storing the message or not. Given spam volumes these days, NOT writing a significant percentage of messages to disk can have a massive impact even when handling a "low" number of concurrent sessions (100-200 should be more than enough to see a difference, though that implies at least a few tens of thousands of active mail users)
Protocols like XMPP can also benefit in terms of memory for any case where the server is acting mainly like a router, as a decision can be made while messages are still incoming to stop storing the message contents and just start pushing the message down the recipient connection. It's a cheap and reasonably simple optimization to make, that if implemented "right" will at the same time throttle the sender to whatever speed the recipient is ready to accept data at, reducing the rate the server needs to process the message with.
Guessing that XMPP won't have much that's computationally costly to do on receipt of a complete message, I agree that you're unlikely to see a huge amount of impact from parsing before a message is complete in normal scenarios.
You're assuming that parser state is going to be larger than keeping an input buffer large enough to keep a complete message.
In the real world, XML is a very verbose protocol, and in most cases it is trivial to store the incoming data in a less space consuming format. Using a SAX parser that is reasonably efficient, the only state you will need to keep track of is namespace declarations and open tags - that is highly unlikely to be much data, and certainly unlikely to get anywhere close to closing the gap between the maximum size of a well parsed data set and the maximum allowed size of a message. As a consequence, a well written server should REDUCE state by parsing as you go, not increase it, and only a complete moron would keep trying to parse the message over and over again from the beginning each time.
Even if this wasn't the case, a well written system would run into bandwidth limitations and IO limitations of the server long before memory limitations in any sane configuration - memory and CPU is cheap, good IO subsystems aren't.
As a benefit of this approach, by the time all the data has arrived from the client, you have the message in a much more efficient representation. In fact, in many cases you might have enough information even before you have received the complete message that you may not even need to store the rest of the message as it comes in.
The idea that you need the complete message before you start doing work on it is flawed - it implies that during sudden bursts of activity, your system will sit mostly idle until complete messages have been received, and then suddenly be swamped with processing, instead of spreading the processing cost over the whole time it takes to receive a message, which could potentially be a "long time" for many clients on slow connections.
Protocols with XML based framing has been in heavy production use for other purposes for years now. Look at EPP for instance (the protocol used for communications between most domain registries and the registrars). EPP over TCP is framed purely in XML. In practice this is a limited problem, since the document level tag "epp" can only occur surrounding a legal document, and the tag isn't used in any other namespaces that would make sense in an EPP document. Hence you read up to the first thing that looks like a valid end tag, and you either have a valid message, or the client botched something.
I haven't read the XMPP RFC, so there might be bigger issues in XMPP, but in real life people tend to find simple solutions to these things.
Cleaner framing might be desirable, but it's not a big issue. Compared to all the junk in various well established protocols (I have a long standing hate for FTP in particular...), XML based framing is trivial.
It didn't start with Vietnam. The US hasn't declared war since World War II. One of the primary reasons for this is that a formal declaration of war is a lot more serious - it concentrates a lot more powers in the hand of the president, allows military censorship of the press, allows internment of national security risks, etc. - and it isn't really needed for conflicts where there is no real threat of attacks on the US. Under international law it doesn't really matter either.
So expect the US to NEVER formally declare war unless there either is no choice (that is, there is a real threat against the survival of the US) or whatever president attempts it wants to move the US towards a military dictatorship...
In other words, you should be bloody thankful that Iraq wasn't used as an excuse for a formal declaration of war.
That was what I was telling people as well: NO US president would have dared justify an invasion of Iraq with land based forces that early on if there was even the slightest chance of a massive chemical, biological or nuclear strike against them - it would be political suicide to send tens of thousands of soldiers in to be slaughtered when Hussein previously had shown himself willing to even attack his own citizens.
It would also have been a strategic suicide, as any attempt to strike back with nukes or similar would likely have made the coalition collapse and cause a tenfold escalation of opposition against the US worldwide.
The only reason the land based invasion started so quickly was because everyone involved in the decisions knew in advance that there would be no WMD's ready for use.
Now, it's quite possible that they believed they were likely to find materials that they could spin as being proof of WMD's, but if they believed Iraq had WMD's ready for use and the will to deploy them, then they also believed they were sending tens of thousands of soldiers to an almost certain death that would also massively reduce their ability to occupy and hold the country.
Does that mean you support US invasion of Israel to remove Sharon and throw Israel out of the illegally occupied areas? If not, why, as they have been systematically ignoring UN resolutions since before Saddam got to power in Iraq in the first plae.
Your analogy fails horribly. Would one be a hypocrite if one only insists it's important to pay for treating one person if there are ten that needs treatment instead of when it's "just" two that needs treatment? If not, why not? You are alleviating the same amount of suffering - why should the number of people left suffering afterwards should have no bearing on your decision?
The fact that one country has more people suffering than another does not make the suffering of those affected any different.
If it is wrong for India to use money on large projects when they have people suffering, then it is also wrong for the US (or any other country).
The thing is, if you focus exclusively on addressing poverty through short term measures, your country will stagnate and fall behind and your economy will collapse, and you will end up worse off than when you started - innovative projects that push technology is a necessity. Yes, it needs to be balanced against other needs, but 88 million is hardly much considering that the US for instance spends hundreds of billions on it's military per year, and about half a billion per shuttle launch.
Reread what I wrote. Women were NOT voting in federal elections in the US beforehand. Women did not get the right to vote in federal elections in the US until 1920, hence my claim that even if being allowed both to vote and to stand in elections would be requirement to be the "most stable democracy", New Zealand still had the US beat.
If you want to discuss whether individual states in the US would fit the bill, then fine, but then expect other people to drag up local regions from elsewhere in the world too.
The CIA factbook definition is meaningless. By that account, Norway and the UK are republics, but both are constitutional monarchies.
There are variations on how a republic elects its president, just as there are variations on what power monarchs have, or how the executive branch is structured in a parliamentary democracy, and some countries even manage to combine elements of all.
But going by the CIA factbook definition would make almost all non-dictatorships republics, while other definitions would make it perfectly possible for a republic to be totalitarian. The term originates from latin - "res publica" ("public affair") - and some apply it to any form of representative government, in which case it does not have to have any relation to democracy.
A federal republic is generally a union of states, not of people, and as such you have a point about Germany, US etc. - a better attempt might be to say that the president is usually elected by representatives of the constitutents of the republic, which in a federal republic is the states (hence the electoral college in the US which in theory represents the states, and the federal convention in Germany).
However definitions meant to classify something as fluid as forms of goverments are difficult to make static - Germany is a variation, as the members of the federal parliament are members of the federal convention.
Also note that my attempts at describing the terms are not mutually exclusive: Germany combines is a federal republic that exercise parliamentary democracy.
Good point... It's a variation: It's a federal republic, just as the US, where the head of state for the federal government is elected by representatives for the states, which is why people in the US vote for representation in the electoral college which elects the president, not the president himself, and in germany the president is elected by a federal convention, which in a quite unusual twist includes the members of the federal parliament..
A federal republic is a union of states, not of people - it is the states that have formed a government to govern certain areas on their behalf. Most federal republics will still have a directly elected parliament.
I'm sure you'll find other examples that are difficult to classify, in which case I'll point out that I was trying to describe "non political-sciences usage" of the terms. I'm sure I could have done better:)
It might be more accurate to say that a republic is a system where the head of state is elected, as opposed to appointed and can not usually be replaced by parliament outside of an election.
The thing is there are almost as many variations of government as there are countries, so often it is a matter of what one wants to emphasise more than clear definitions.
Define democracy. Britain during in that timeframe had extremely limited participation (property requirements, no women, no votes to colonial subjects etc.) so that people who actually had any say didn't actually make up more than a tiny fraction of people who were ruled by the British crown and parliament.
Since then, Britain has also fought wars with a long range of it's subjects resulting in the collapse of the empire. How is that stable?
Britain lost Ireland, has needed to use extended military intervention in Northern Ireland, with massive political disruption in the region.
Even disregarding all that, it still isn't the oldest democracy - not even the oldest in Europe.
I don't agree with you. One poster made the argument that it's horrible for India to "vaste" money this way. Another poster makes the argument that the US is in the same situation, the point being that either the original poster should be equally horrified at both, or not at either. It is a way of determining whether the person who made the original argument is a hypocrite.
It is completely valid to question whether this concern over how India spend it's money is because the person in question is concerned about any expensive project while people suffers, in any country, or whether it is just some misplaced idea that people only suffer in developing countries and that space programs somehow are worthless and make up a significant part of any countries expenses when fact is that no country is free of suffering, and space programs tend to be miniscule (even in the US) compared to things like military expenditure that usually gets much less heat.
And I think the hundreds of billions the US spends on maintaining a military and illegally invading other countries could be much better spent, especially in a country like the US where a lot of people don't even have access to basic modern comfort.
A space program isn't a pissing contest - all countries depend on space technology in one way or another. For a country with more than a sixth of the worlds population it would be lunacy to depend on other countries for things like military surveillance, communications, weather monitoring, etc. It would also be lunacy to let other nations cement their technical superiority and hold onto their grip on a market that is growing extremely rapidly, and will be a vital revenue source in a few decades.
Actually, even if they don't stay in India it is still likely to be a net benefit for the country. Most expats, regardless of country of origin, send money "back home" in one way or the other, be it to help family - which is even more prevalent for expats from poor backgrounds -, in buying products from their native country, travelling back and spending money during vacations etc. You will also find that a not insignificant number of economic emigrants return if they are successfull, because they prefer their home country and want to live there, but didn't like their economic conditions.
India already have a significant stream of Indians moving back to the country as the number of "high paid" (by local standards) technology jobs have been rapidly increasing.
And a project like this could easily include a lot of well paid high prestige jobs - if it boosts India's reputation as a reliable partner for satellite launches, and local firms are prioritized for purchases for the project wherever possible, the return could easily be many times the investment.
You can make this argument against practically any investment. However India has demonstrated quite clearly over the last few decades how important investing in technology development is to creating wealth - it is a way of moving straight from a predominantly low tech agrarian society to high yield export markets that draw massive amounts of foreign cash into the country without requiring the massive infrastructure investments that heavy industry does.
A space program may not have that many direct benefits, but indirectly, in increasing the prestige of Indian as a nation with significant engineering and research resources, it will have huge knock on effects in terms of investments in Indian companies.
If you want to criticise projects that keep money from being used on social problems, at least focus on things that for most countries are huge drains on the economy and on foreign cash reserves, such as large weapons purchases etc. that make this moon program look like peanuts.
It's not about being radical. Governments have a long history of requiring documents to be filed with them in whatever format suited them. Thus as soon as some agency that lots of people interact with switches to OO it's just a question of time before one of them gets the bright idea to require people to submit documents in OO format to simplify things internally.
You forget that US women couldn't vote in federal elections until 1920, so New Zealand still wins if you require both to be able to vote and stand to consider it a democracy.
So, whilst Britain is technically a consitutional monarchy it is effectively a democratic republic in all but name.
That is a rather pointless statement. A democratic republic is a democracy whose head of state is directly elected. Contrast this with a constitutional monarchy, where the head of state is a hereditary position. Britain is the latter, the US the former.
Constitutional monarchies tend to be parliamentary democracies. A parliamentary democracy is a country where the executive (typically a cabinet lead by a prime minister) requires the ongoing support by parliament (though in some constitutional monarchies, such as Norway, the head of government is appointed by the head of state, the parliament can still throw the cabinet out, and it is extremely unusual for the head of state to choose a prime minister that has not already secured the support of the parliament in advance).
Some republics are also parliamentery democracies (Iceland and France for example), while others, such as the US are not.
So I guess what you probably meant is right - the differences are quite small, and both are practical adaptations of democracy, but looking at various Western systems, the US and British systems are two of the most dissimilar, perhaps except for one man circuits that cause very low number of parties represented in government.
Actually, it depends on a state by state basis - Maine and Nebraska already distribute votes between the candidates depending on who wins what congressional districts. But many states also have laws on the books requiring the electors to vote for the candidate that got the most votes from that state, instead of merely providing electors that have pledged to vote for a specific person. So while the electors in theory could, and sometime have, voted differently than they were "supposed to", I don't think it has ever had an effect on the outcome of an election.
Ehm.... Only the priviledged could vote in the US too until the mid 1800's when the restrictions on property ownership and religion (being a christian was a requirement many places - catholics did not need apply) were lifted. And your attempt at explaining away how Indians, blacks and women not being allowed to vote (and in the case of blacks, not getting anything like equal opportunity to vote until the 1960's) is kind of tragic.
Contrast with New Zealand, which had full universal suffrage from 1893, or the dozen or so other countries with universal suffrage before 1920 (when the US got it, unless you happen to be a poor descendant of a slave and where still massively discouraged from voting through poll taxes and the like).
And your handwaving about the civil war is truly precious.
Essentially, you're trying to defend the statement by defining away most countries ("large scale"), ignoring a war fought to force a significant part of the country from seceding, ignoring the fact that significantly less than half the population could vote (after the 1840's - before that the number was a tiny fraction, due to property ownership restrictions etc)
Newsflash: By redefining the issue, any answer can be the right one...
And the US does? Why don't you look at the list of wars the US have STARTED over the last couple of hundred years. And as for human rights, why don't you take a look at the measures that had to be taken before blacks finally got the same opportunity to vote as whites in the 60's.
Slashdot Mirror
I've implemented this approach for various protocols several times, and it does wonders for latency, and can save quite a bit of memory as well if messages are potentially large.
I just for my bare life can't see why you think it would be inelegant, more error prone or more work. Pseudocode to illustrate:
... handle pending writes...
Main loop:
while (not shutdown) {
select(sockets)
for (each socket that is readable) {
read(socket, buffer, sizeof buffer);
mySaxParser.parse(buffer)
}
}
Start tag handler:
openTags.push();
if (openTags.size() >= 1) pickDataToStoreForProcessing();
End tag handler:
poppedTag = openTags.pop();
if (poppedTag != closed tag) error();
If (openTags.size() == 1) processMessage(...) (document tag for XMPP is the "stream" tag, which encloses all the messages, so 1 open tag means an enclosed message was just closed)
Care to explain how different framing would make the above so much better?
You're stuck with an XML parser since the documents you are dealing with are XML anyway, so what little overhead you're dealing with in terms of matching up tags and checking for the end of a message is completely trivial compared to the amount of code handling the parsed data will take regardless of framing, and shouldn't even show up in profiling.
If storage and performance is really a concern, you might gain a tiny little bit by using an XML tokenization library directly instead, to make 100% sure there is no duplication of state, but most of the time there won't be any point.
Once you've done this kind of thing a couple of times, you'd write this kind of basic infrastructure in your sleep, or reuse a generic template.
It's also a structure that scales very well, because many operations can be started before a message is complete. For instance if you're routing messages you might start pushing them to the recipient as soon as you know where to send it, throwing away state as soon as it's been successfully written. The effect on latency can be quite dramatic for very little additional work.
First of all, a long stream of Jabber messages is irrelevant - you won't be handling more than the greater of your IO buffer (and don't try to tell me 100MB would be a sensible size) or one XML stanza and parts of another at most - so unless you're leaking memory the length of the stream have absolutely no bearing. The IO buffer size is a tradeoff between performance and memory usage, but can be fairly large since in a multiplexed environment it will be shared between all the connections when you are parsing the message as you go.
If you want to parse the message at the end, however, you'd need to retain a copy of the message.
Second, a SAX parser needs to maintain only very limited state between calls - it needs the XML namespace declarations and a list of open tags, and enough space to hold a single incomplete token. I'm sure you can find implementations that keep all kinds of extra around, but I've both used and written parsers that have made do with just the above.
The general approach then is to maintain a fixed size IO buffer, fill it as much as possible with a single non blocking read (which btw. is another reason to consider interspersing processing with the reads, as you for some workloads otherwise end up context switching to fill up only small parts of the buffer at a time), feed it to the SAX parser. If any events are fired, your code looks at the data and throw away any parts it doesn't need, or stores it in whatever more compact form is convenient for you. If the message is complete, process whatever stored data you have gathered from it, and throw away afterwards. Repeat as long as the connection remains active.
Since XML usually is extremely redundant, it is normally trivial to come up with an internal representation that is more space efficient than raw XML, but many applications (including XMPP) don't even need all the data from many messages - often you only need to store parts of the data you are receiving. If space is really important for you, and you're dealing with limited XML vocabularies, this is particularly true, as "compressing" the XML can be very efficient.
Applying this to multiplexed IO is exactly the same as for the single connection case. You maintain the state required per socket. Each time the socket becomes readable, you fill the buffer as much as possible, and feed the SAX parser.
No, it's not guaranteed to always save space - if you NEED to do processing on the raw XML for whatever reason, or NEED all the data before you can do processing that allow you to throw some of it away (after passing it on to another client or server for instance), you could apply compression techniques to your IO buffer without parsing the XML and might end up doing better, but I've yet to come across a single real life application where that would have been a useful approach.
That said, I'd not usually spend time doing any of this except as a side effect of the convenience of storing the data in a more useful form than raw XML, as memory is cheap and developer time isn't. Given relative component costs it's almost always IO performance that is the most cost effective to optimize in the kind of systems I've dealt with.
However reducing context switches is often quite straightforward. I'm shocked at how often I see network code where read() is called with ridiculously small buffers because people can't be bothered to maintain userspace buffers to do read()'s across frame boundaries in stream oriented applications and end up only read()'ing whatever amount of data they happen to know belongs to the current frame, for instance. Once an application is well structured with respect to use of system calls etc., I rarely see applications where context switches are much of an issue on a well tuned system.
You're right that the case I suggested in what you quoted above is unlikely to be a problem in many ordinary scenarios, but one case where it can be an issue is for instance if you're on the receiving end of massive mailing list blasts from badly set up mail servers (or spammers). Many other services that have potentially "hostily users" as clients have patterns where sudden surges of traffic may occur, and where there may be "considerable" (compared to the cost of parsing the message stream itself) costs to process the message.
For mail servers in particular, which are usually almost entirely dominated by disk IO (typical CPU usage on the MX's of a system I worked on connected to an IBM Enterprise Storage System was around 10-15%) being able to start filtering as soon as you've received the first byte of a message allow you to very quickly take actions to determine whether to keep storing the message or not. Given spam volumes these days, NOT writing a significant percentage of messages to disk can have a massive impact even when handling a "low" number of concurrent sessions (100-200 should be more than enough to see a difference, though that implies at least a few tens of thousands of active mail users)
Protocols like XMPP can also benefit in terms of memory for any case where the server is acting mainly like a router, as a decision can be made while messages are still incoming to stop storing the message contents and just start pushing the message down the recipient connection. It's a cheap and reasonably simple optimization to make, that if implemented "right" will at the same time throttle the sender to whatever speed the recipient is ready to accept data at, reducing the rate the server needs to process the message with.
Guessing that XMPP won't have much that's computationally costly to do on receipt of a complete message, I agree that you're unlikely to see a huge amount of impact from parsing before a message is complete in normal scenarios.
In the real world, XML is a very verbose protocol, and in most cases it is trivial to store the incoming data in a less space consuming format. Using a SAX parser that is reasonably efficient, the only state you will need to keep track of is namespace declarations and open tags - that is highly unlikely to be much data, and certainly unlikely to get anywhere close to closing the gap between the maximum size of a well parsed data set and the maximum allowed size of a message. As a consequence, a well written server should REDUCE state by parsing as you go, not increase it, and only a complete moron would keep trying to parse the message over and over again from the beginning each time.
Even if this wasn't the case, a well written system would run into bandwidth limitations and IO limitations of the server long before memory limitations in any sane configuration - memory and CPU is cheap, good IO subsystems aren't.
As a benefit of this approach, by the time all the data has arrived from the client, you have the message in a much more efficient representation. In fact, in many cases you might have enough information even before you have received the complete message that you may not even need to store the rest of the message as it comes in.
The idea that you need the complete message before you start doing work on it is flawed - it implies that during sudden bursts of activity, your system will sit mostly idle until complete messages have been received, and then suddenly be swamped with processing, instead of spreading the processing cost over the whole time it takes to receive a message, which could potentially be a "long time" for many clients on slow connections.
I haven't read the XMPP RFC, so there might be bigger issues in XMPP, but in real life people tend to find simple solutions to these things.
Cleaner framing might be desirable, but it's not a big issue. Compared to all the junk in various well established protocols (I have a long standing hate for FTP in particular...), XML based framing is trivial.
So expect the US to NEVER formally declare war unless there either is no choice (that is, there is a real threat against the survival of the US) or whatever president attempts it wants to move the US towards a military dictatorship...
In other words, you should be bloody thankful that Iraq wasn't used as an excuse for a formal declaration of war.
It would also have been a strategic suicide, as any attempt to strike back with nukes or similar would likely have made the coalition collapse and cause a tenfold escalation of opposition against the US worldwide.
The only reason the land based invasion started so quickly was because everyone involved in the decisions knew in advance that there would be no WMD's ready for use.
Now, it's quite possible that they believed they were likely to find materials that they could spin as being proof of WMD's, but if they believed Iraq had WMD's ready for use and the will to deploy them, then they also believed they were sending tens of thousands of soldiers to an almost certain death that would also massively reduce their ability to occupy and hold the country.
Does that mean you support US invasion of Israel to remove Sharon and throw Israel out of the illegally occupied areas? If not, why, as they have been systematically ignoring UN resolutions since before Saddam got to power in Iraq in the first plae.
The fact that one country has more people suffering than another does not make the suffering of those affected any different.
If it is wrong for India to use money on large projects when they have people suffering, then it is also wrong for the US (or any other country).
The thing is, if you focus exclusively on addressing poverty through short term measures, your country will stagnate and fall behind and your economy will collapse, and you will end up worse off than when you started - innovative projects that push technology is a necessity. Yes, it needs to be balanced against other needs, but 88 million is hardly much considering that the US for instance spends hundreds of billions on it's military per year, and about half a billion per shuttle launch.
If you want to discuss whether individual states in the US would fit the bill, then fine, but then expect other people to drag up local regions from elsewhere in the world too.
There are variations on how a republic elects its president, just as there are variations on what power monarchs have, or how the executive branch is structured in a parliamentary democracy, and some countries even manage to combine elements of all.
But going by the CIA factbook definition would make almost all non-dictatorships republics, while other definitions would make it perfectly possible for a republic to be totalitarian. The term originates from latin - "res publica" ("public affair") - and some apply it to any form of representative government, in which case it does not have to have any relation to democracy.
A federal republic is generally a union of states, not of people, and as such you have a point about Germany, US etc. - a better attempt might be to say that the president is usually elected by representatives of the constitutents of the republic, which in a federal republic is the states (hence the electoral college in the US which in theory represents the states, and the federal convention in Germany).
However definitions meant to classify something as fluid as forms of goverments are difficult to make static - Germany is a variation, as the members of the federal parliament are members of the federal convention.
Also note that my attempts at describing the terms are not mutually exclusive: Germany combines is a federal republic that exercise parliamentary democracy.
A federal republic is a union of states, not of people - it is the states that have formed a government to govern certain areas on their behalf. Most federal republics will still have a directly elected parliament.
I'm sure you'll find other examples that are difficult to classify, in which case I'll point out that I was trying to describe "non political-sciences usage" of the terms. I'm sure I could have done better :)
It might be more accurate to say that a republic is a system where the head of state is elected, as opposed to appointed and can not usually be replaced by parliament outside of an election.
The thing is there are almost as many variations of government as there are countries, so often it is a matter of what one wants to emphasise more than clear definitions.
Since then, Britain has also fought wars with a long range of it's subjects resulting in the collapse of the empire. How is that stable?
Britain lost Ireland, has needed to use extended military intervention in Northern Ireland, with massive political disruption in the region.
Even disregarding all that, it still isn't the oldest democracy - not even the oldest in Europe.
It is completely valid to question whether this concern over how India spend it's money is because the person in question is concerned about any expensive project while people suffers, in any country, or whether it is just some misplaced idea that people only suffer in developing countries and that space programs somehow are worthless and make up a significant part of any countries expenses when fact is that no country is free of suffering, and space programs tend to be miniscule (even in the US) compared to things like military expenditure that usually gets much less heat.
And I think the hundreds of billions the US spends on maintaining a military and illegally invading other countries could be much better spent, especially in a country like the US where a lot of people don't even have access to basic modern comfort.
So it is amoral and shortsighted to invest in developing local technology so that local industry thrive and help catch a pie of the multi-billion dollar satellite launch market by proving their capabilities, so they get foreign business, creating thousands of jobs in the process, and bringing in billions of foreign capital to grow their economy?
So it is amoral and shortsighted to invest in communications systems to help boost education levels in poor rural areas?
A space program isn't a pissing contest - all countries depend on space technology in one way or another. For a country with more than a sixth of the worlds population it would be lunacy to depend on other countries for things like military surveillance, communications, weather monitoring, etc. It would also be lunacy to let other nations cement their technical superiority and hold onto their grip on a market that is growing extremely rapidly, and will be a vital revenue source in a few decades.
India already have a significant stream of Indians moving back to the country as the number of "high paid" (by local standards) technology jobs have been rapidly increasing.
And a project like this could easily include a lot of well paid high prestige jobs - if it boosts India's reputation as a reliable partner for satellite launches, and local firms are prioritized for purchases for the project wherever possible, the return could easily be many times the investment.
A space program may not have that many direct benefits, but indirectly, in increasing the prestige of Indian as a nation with significant engineering and research resources, it will have huge knock on effects in terms of investments in Indian companies.
If you want to criticise projects that keep money from being used on social problems, at least focus on things that for most countries are huge drains on the economy and on foreign cash reserves, such as large weapons purchases etc. that make this moon program look like peanuts.
It's not about being radical. Governments have a long history of requiring documents to be filed with them in whatever format suited them. Thus as soon as some agency that lots of people interact with switches to OO it's just a question of time before one of them gets the bright idea to require people to submit documents in OO format to simplify things internally.
You forget that US women couldn't vote in federal elections until 1920, so New Zealand still wins if you require both to be able to vote and stand to consider it a democracy.
That is a rather pointless statement. A democratic republic is a democracy whose head of state is directly elected. Contrast this with a constitutional monarchy, where the head of state is a hereditary position. Britain is the latter, the US the former.
Constitutional monarchies tend to be parliamentary democracies. A parliamentary democracy is a country where the executive (typically a cabinet lead by a prime minister) requires the ongoing support by parliament (though in some constitutional monarchies, such as Norway, the head of government is appointed by the head of state, the parliament can still throw the cabinet out, and it is extremely unusual for the head of state to choose a prime minister that has not already secured the support of the parliament in advance).
Some republics are also parliamentery democracies (Iceland and France for example), while others, such as the US are not.
So I guess what you probably meant is right - the differences are quite small, and both are practical adaptations of democracy, but looking at various Western systems, the US and British systems are two of the most dissimilar, perhaps except for one man circuits that cause very low number of parties represented in government.
Actually, it depends on a state by state basis - Maine and Nebraska already distribute votes between the candidates depending on who wins what congressional districts. But many states also have laws on the books requiring the electors to vote for the candidate that got the most votes from that state, instead of merely providing electors that have pledged to vote for a specific person. So while the electors in theory could, and sometime have, voted differently than they were "supposed to", I don't think it has ever had an effect on the outcome of an election.
Contrast with New Zealand, which had full universal suffrage from 1893, or the dozen or so other countries with universal suffrage before 1920 (when the US got it, unless you happen to be a poor descendant of a slave and where still massively discouraged from voting through poll taxes and the like).
And your handwaving about the civil war is truly precious.
Essentially, you're trying to defend the statement by defining away most countries ("large scale"), ignoring a war fought to force a significant part of the country from seceding, ignoring the fact that significantly less than half the population could vote (after the 1840's - before that the number was a tiny fraction, due to property ownership restrictions etc)
Newsflash: By redefining the issue, any answer can be the right one...
And the US does? Why don't you look at the list of wars the US have STARTED over the last couple of hundred years. And as for human rights, why don't you take a look at the measures that had to be taken before blacks finally got the same opportunity to vote as whites in the 60's.