The reason evolution is taught (and taught almost as though it were accepted fact), while other theories (not ID, which does not qualify as a theory for reasons others have mentioned) are not, is that evolution is the prevailing paradigm in the field. That paradigm will be adhered to, and the horse of evolution flogged like you wouldn't believe, until such time as it is proven or it ceases to explain the evidence collected in the pursuit of its verification-- and likely for some time afterward, until a new paradigm that does accomodate that evidence is established. If neither proof nor disproof ever happens, and the body of evidence supporting evolution continues to grow, then it can only be said to be increasingly more likely that the theory is correct than that it is not.
That's a brief summary of Kuhn's Structure of Scientific Revolutions, which has been a pretty standard text for scientists for forty years. Grab a copy and read it, if you haven't-- it's a short, easy read, and gives you the broad view of how science works, and why. Why the hell I wasn't exposed to it until college, I don't know.
I left a Trek locked to a bike rack for anyone who wanted to ride it, and later left a Fisher in the hallway of the house I was renting for anyone who wanted to ride it.
It was never a good idea to rely on a third party such as Gamespy to provide a branded in-game browser. For one, that reliance drives up development costs for licensing fees.
As opposed to the cost of developing it yourself? If that were true, nobody would license Gamespy.
Are you actually updating the posts in your feed that frequently? If not, you might want to figure out why your server isn't sending 304s. Here's what bloglines looks like to me:
Last month, the most popular blog on my server transferred about 200MB of data (very few images on this site). 900k of that went to bloglines, which polled every hour all month long.
Yes, an ancient, alien artifact, pregnant with long-dormant, world-ravaging evil, which will no doubt unleash terrible plague and death and destruction the world over, consuming the entire human race in an unimaginable apocalypse, only possibly averted by some unlikely everyman hero who has heretofore been overlooked by society but who will, no doubt, be immortalized by his deeds on the day the evil is returned to this artifact and banished forever.
I've already posted, so I can't mod this AC's post up for visibility. Someone maybe should, since it's the only actual response to Alan's question, and this seems a point worth discussing.
According to Sun's CDDL site the change was made to simplify the license:
The required notices in the MPL regarding third party claims and patents (formerly in MPL Section 3.4(a) and 3.4(b)) have been eliminated; they seemed overly burdensome and likely to prevent wider acceptance of the license by by the community. Additionally, none of the other major open source licenses (e.g., GPL, BSD, CPL, OSL) require such disclosures.
The terms of section 2.2 grant a world-wide, royalty-free, non-exclusive license to any patent rights the contributor knows about and section 3.2 makes contributors assert they have rights to their contributed code so I can't help thinking you're being a bit extreme - seems the simplification is appropriate as the bases are covered.
(Pls mod up the original AC response, and mod down this one.)
Sure, but not because I work at Sun. Like I said, I don't have anything to do with this stuff.
So, besides distributing patches to software, we can start distributing patches to licenses as well?
The provision you quoted is nothing new, and I really don't see what the big deal is. From the GPL:
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number.
counter-disclosure: I read about this on CNet, just like everyone else, and I don't know any more about this than is available at Sun's CDDL site. Also, I don't really work anywhere near the Solaris group.
The CDDL is just a refinement of the MPL-- and I've read the redline diffs, and there doesn't seem to be anything sinister or extra-restrictive about the changes.
The MPL is nice, in that it is propagative but not viral. That is, if you distribute a modified binary you have to distribute the source for your modifications, but you can use MPL-licensed code in a larger project without any effect at all on the license of the larger project.
The only reason GPL compatibility is even an issue is that there was some hope that Solaris code could be picked up and used in Linux-- which I really think was pretty optimistic. Techniques learned from the Solaris source may be transferrable, though, and I think still will be as long as the Solaris source is truly open.
You're right in your follow-up that restricting suffrage to males is idiotic.
You forgot that restrictiing it to property owners is also idiotic. Do you really think that because I rent my home, I have less stake in the decisions of government than does some guy with a 1/20th-acre townhouse plot?
Poll tax? The poor have no stake in government? The poor have a great many problems that can only be addressed by government, and a great many of them are caused by government policy. I think they should get a damn vote.
A test? In a nation that is split almost 50/50 on every major issue, who are you going to get to write this test without disenfranchising half the population? The Ministry of Truth?
Expanding suffrage to everybody does lead to better government than the alternative, which is what we call oligarchy. Of course, I define "better" as "more representative of and responsive to the people", not "in agreement with me specifically". I understand that's very trendy of me.
That doesn't do anything. As a programmer, I can tell that machine whatever I want to print on the paper, and still tell the machine internally to record something else. There's a fundamental problem with that. When that voter leaves, and they start tallying up all the WRONG votes later on, what are they going to do about that? Answer: Nothing. The voter has already left, the polls are closed. Basically, when they find those faulty votes in machines, the machine doesn't count. So X number of voters just lot their right to vote.
You seem to be fixated on the voter's verification of the receipt as the primary solution, when in fact it is simply there to enable the real solution-- recounts using physical ballots. If there are suspicious results from a precinct, you do a recount using the paper receipts that voters verified and deposited into a locked ballot box. In other words, you revert to a paper-ballot system for that precinct. It would not be a bad idea to do this for random precincts regardless of suspicion, or even to do it for all precincts all the time-- you would still have some very real benefits the machines provide (unambiguous input, multilingual displays, etc.), so it wouldn't be a wash.
They don't have to show the public anything. The laws in place prevent them from having to do that. The only reason they as an industry would, is out of good will. Election software is what they make their living on. Why would a company open source the code when that's how they make money?
I never laid this problem solely at the feet of the system manufacturers, and frankly I think you misunderstand the solution. The solution is voter-verified receipts which can be referred to after the election to cross-check the machine tallies. You'll note that I didn't say anything about open-sourcing the software. I think that's necessary, and if anything it could well lead to a false sense of security. Voting machines must always be considered and treated as untrustworthy black boxes, and their output must always be verifiable against their input. Opening the source to the software is not helpful.
Election companies don't determine what the public uses...it's the other way around. The laws in each jurisdiction determine what the company's equipment does. Maybe everyone bitching should go look at the laws on their books in each state and examine why those laws don't call for a voter-verifiable-paper-trail.
You also seem to think that I want the manufacturers to pretty-please help us out here, whereas most of the people who share my views are calling for law requiring a solution like the one I described. If that law has to replace some current law that specifies the machines as they are, fine.
1. The paper receipt is there as a justification tool against what's on the memory cards or electronic storage media. It doesn't guarantee though that the vote hasn't been tampered with. It could very weel be tampered with while the person is pushing the "vote" button.
The receipt doesn't have to guarantee that the vote hasn't been tampered with. It does two things:
Provides the voter assurance that the machine read the voter's input correctly
Serves, as you say, as a tool for verification of the automated vote tallies
There must always be some record against which a vote collection and tabulation system's results can be verified. Otherwise, you have no way of knowing that something inside that black box didn't go wrong.
This is taken from a post I made a while ago to my own blog:
When we test software, we treat it as a black box. Here is how we tell if a black box is doing what its supposed to do:
Feed some input into the box.
Look at the output the box gives you back.
If the output you get reflects the input you gave, everything is ok. If not, the box isnt working right.
In the case of a voting machine, the input is the ballots that are cast for the election. The output is the vote tallies. The trick is that in an election, the people who do Step 1 and Step 3 are not the same people. Voters provide the input, but if output is to be verified against that input, election officials must have the input available. This means that for Step 3 to be possible in an election, the ballots must be kept around.
Now, we do not trust the machines. The machines are black boxes, and we dont know what goes on in there. Therefore, it should always be possible to test the machines. That means we cannot let the machines have sole responsibility for keeping those ballots around, because they might keep bad records. To use another analogy: You do not put a suspected embezzler in charge of your ledgers, because that makes it impossible to reliably audit him. Instead, every time you entrust the suspected embezzler with some money, you get a receipt and make a record in your own ledger.
What are needed in the case of e-voting systems are receipts and a ledger. When you give the machine your ballot, it should recite that ballot back to you as a paper copy. If there is a discrepancy between what you think youve given the machine, and what it tells you youve given it, thats a red flag. If there isnt, you put the receipt into an opaque box the elections ledger. That box of receipts stays with the election officials, who are presumed trustworthy as they always have been. After the election, if there is any doubt about the machines honesty, the receipts can be counted in other words, the machines accounting can be reconciled against the ledger.
This is not a problem with the people running the machines. This is a problem with the software running on the machines, and possibly the people who made that software.
This machine's entire purpose in life is to count, and to count with perfect reliability. I'm a software quality engineer, and there is no way a bug of this sort would have made it past my team without all hell being raised-- and not just internally, given the product.
It's just not that hard to test a counting machine. Any freshman CS major can tell you what that machine should have done when it found it couldn't handle more votes. (Throw an error message and keep accepting votes? No.) The problems we're seeing can only be caused by extreme incompetence or by malice.
It's taking your eye off the ball to look for the problem in the operators rather than the machines and manufacturers.
And if the nerd tells them that Ogg support should be a major factor in their decision, they will stop listening to the nerd, who is obviously just being a nerd.
You might think of yourself as some sort of High Priest of Gizmos, but people aren't stupid. They know that if they've never heard of Ogg, they have no reason to give a damn if their gizmo can't play it.
Besides, you have to be a special kind of jackass to recommend a gizmo to someone based on its support for a format that you care about, but which you know that they don't.
$250 for a music machine? I can get a cd "WalkMan" for $50, less if I go for an off brand, more if I go for a major brand. Thats a nice price, I can afford to buy one if I want one. At $250 it is no longer a buy if I want it budget item, but something most people have to think twice about.
Okay, so let's assume you're right and $250 is too much for most people. So what? What bearing does that have on anything at all?
This is an article about the iPod's competition, not the great mystery of why the entire population of the industrialized world hasn't bought an iPod yet.
If we had instant runoffs, Nader wouldn't have any influence whatsoever.
Think about this for a minute, and assume that only Kerry, Bush, and Nader are running. Nader supporters would vote Nader/Kerry, moving from the left incrementally toward the center. Bush supporters would vote Bush/Kerry, on the same logic, and Kerry supporters would vote either Kerry/Nader (if they're left-leaning) or Kerry/Bush (if they're right-leaning).
Now, there are a hell of a lot more people who would choose Kerry or Bush as their first choice, or as their second choice, than would choose Nader at all. Result? An instant run-off would be between Bush and Kerry, and Nader would just vanish altogether. It would be as if he hadn't run.
If such were the case, Nader wouldn't even have the limited voice and influence he now does, as he could be safely ignored by the other two parties and therefore by the vast majority of the electorate.
Who are these people that would vote for Nader if he was on the ballot, but will vote for Kerry if Nader is not on the ballot?
I imagine they're the ones that respond to the poll question "who are you going to vote for?" with "Nader", and then the follow-up question "If Nader weren't in the race, who would you vote for?" with "Kerry". But I could be wrong.
Are you serious? Do you have any idea how many locally elected officials there are in this country? The fact that this party can list all of its locally elected officials on one page only speaks to how miniscule it is. Even if they were all mayors, that would be pathetic... but I'm looking at a list full of "Georgetown Zoning Board of Appeals", and "Tioga County Forestry Advisory Board".
Get real. The LP is not massive, and there is no conspiracy to silence and marginalize it.
I think, and I could be wrong about this, if you select "credit", then the credit card companies make money off of your transaction.
You know, I hear this a lot, even from people with the same debit card I carry. I often hear it after I tell a cashier to treat it as a credit card, from someone who's looking at me like I'm a fool who's just parted with his money.
It may be that Visa gets some money, but I don't care. It doesn't come out of my pocket.
Is there a difference between signing a receipt and using my PIN to authorize a Check Card purchase?
Your options may differ depending on the merchant. Some merchants may require a signature (such as many restaurants), while others may offer you the option of 'Credit' or 'Debit/ATM' when processing your purchase. Usually, if you select 'Credit', you will sign a receipt to authorize your purchase. If you select 'Debit/ATM', you will use your PIN.
Whether you select 'Credit' or 'Debit/ATM', the purchase amount will be deducted from your Bank of America checking account. Generally, there is no transaction fee for either type of transaction. (Merchants may charge a fee)
Federal driver's license standards were actually enacted in 1997 (and set to go into effect in 2000), but in 1998 South Carolina successfully challenged the constitutionality of federal regulation of state drivers' licenses. It was different law, but the same principle, and in 1999 the Congress repealed the 1997 law.
More detail here, under the "Constitutional Issues" section. (References are given.)
Funnily enough I do. I'm working on a telco project and strangely enough data throughput is the most (MOST!) important parameter of the whole thing. XML was considered and binned for exactly the reasons I gave. Considering the whole project has so far taken 3 years using up a week or 2s developement time to implement a packet tx/rx system was irrelevant. Seems to me like you've only ever worked on mickey mouse projects where 1 week is a significant proportion of the total time.
Ah, it all becomes clear. Look, not everyone is working on telco projects "where data throughput is the most (MOST!) important parameter of the whole thing". Obviously if you're working on a project where speed trumps all, you don't want XML. My point is that such projects are in the minority, that projects which would use a message-passing protocol like XMPP are not in that minority, and that you cannot base an assessment of XML in the context of XMPP on whether or not XML is a suitable format for a low-level network protocol. XML is a suitable and very advantageous format for something like XMPP, for the reasons I've given in previous replies to your pigheaded, myopic posts.
The fact that a screwdriver didn't work for banging your nail does not mean that nobody uses screws and the screwdriver is useless in all contexts.
Those of us who do real network programming as opposed to high level toy coding , do.
Bully! That's the right tool for that job. But it is not the right tool for most jobs, and it's not necessarily the right tool for something like XMPP. Which was my whole point when you think about it, right?
This is descending into farce. I think my previous refutations of your posts are scored highly enough that people will see them, and I'm not all that interested to see whether you actually believe that all software development is throughput-centric telco software development, so I'm done. Thanks for the good times.
Then what is? Because I can't think of any other good reasons.
Fortunately, you don't have to. I provided you with a brief list later in my reply.
Thats a bit like saying you can make a go-kart go really fast if you try. Yeah great , but why not just buy a car in the first place then?
You've got your comparison backward. Your whole argument was that a car (XML), which is larger but is more versatile, wasn't as small as a go-kart (compact, binary format). My point was that if you want, you can negate the size difference while retaining the versatility of the car, so your argument is moot.
So what , its still just a shell! So you can download some parser to parse it. Oh well great, that saves a weeks development time. And slows down the whole product whenever its run. Hmm , great tradeoff. Not.
It's again clear that you've never actually developed with XML. If you really care about speed (or need to reduce memory use), you work with SAX streams instead of DOM or other object models. You might take a speed hit compared to working with byte-delimited chunks of binary data, but it will be of a scale you're certainly not going to care about in message-passing, which tends to be a sparsely executed operation anyway.
I'm also beginning to wonder whether you've actually got a job, as saving a week's development time is often the difference between whether the project gets done or not. In the context of XMPP, this could be a major factor in adoption of the protocol-- bear in mind that's a week's development time saved for every implementation of the protocol.
No , theres nothing special about "messages" that means they all have to use a standard format. Why shoehorn everything into the same dumb standard? Horses for courses...
Bear in mind that I'm talking about the messaging protocol (carrier format), not the payload. If your protocol requires changes, isn't it good to be able to add information without necessarily breaking older implementations of the protocol? Wouldn't it be good if they could simply ignore information relating to features they don't support? You can't do that in a byte-delimited binary format without careful and specific pre-planning, the effort of which may be wasted if you're not sufficiently prescient.
Absolute fastest speed and optimum compactness are not everything, and are usually pretty far down on the list of requirements even for an application-level network protocol. They are almost always trumped by minimizing development effort, maximizing extensibility and maintainability, and standards compliance (yes, even of "shells"). If this weren't the case, we'd all be writing everything in C and doing pointer math on arrays of gobbledygook all the time.
XML is when something has to be human readable and unless its for the benefit of some line tapping hacker who the hell is going to read IM packets?
No, it's not. If you'd ever developed with XML, you'd know human-readability is not a major reason to use it.
Not only is XML bloated and so sucks up bandwidth (important if you're still on dial up) but its slow to parse and generally ugly.
XML compresses amazingly well. I have an OpenOffice spreadsheet that's 25MB in uncompressed XML. Zipped up, as OpenOffice files are, it's about 150k. That's an extreme example, but grab any xhtml web page and gzip it.
"But its for developers!" someone shouts. I'm sorry? Just how dumb a developer do you have to be to not be able to grok some efficient binary protocol? "But its a standard" someone else shouts. No it isn't. XML is a shell , you can fill it with any old shit and just because something else is "XML based" doesn't mean it will understand it.
Yes, but XML is a standard shell. Data encoded in XML can be parsed, looked up, accessed, transformed, and represented in code using off-the-shelf toolkits which are extremely good at doing all of those things. You don't have to fuck about writing a parser and a lexer, you can just grab some stuff off Jakarta and go to work on your application instead of its IO format. Furthermore, XML is extensible (that's what the X is for)... if your format requires additional information in the future, or needs to act as a carrier for another format's info, that's already taken care of. Probably a good thing for a message-passing protocol, don't you think?
Using XML for IM is a clear case of jumping on the bandwagon for no reason other than the sheep mentality coming to the fore.
Funny, my first thought when I saw your post was "oh look, another cynical-but-wise wrong-tool-for-the-job anti-XML post".
Slashdot Mirror
The reason evolution is taught (and taught almost as though it were accepted fact), while other theories (not ID, which does not qualify as a theory for reasons others have mentioned) are not, is that evolution is the prevailing paradigm in the field. That paradigm will be adhered to, and the horse of evolution flogged like you wouldn't believe, until such time as it is proven or it ceases to explain the evidence collected in the pursuit of its verification-- and likely for some time afterward, until a new paradigm that does accomodate that evidence is established. If neither proof nor disproof ever happens, and the body of evidence supporting evolution continues to grow, then it can only be said to be increasingly more likely that the theory is correct than that it is not.
That's a brief summary of Kuhn's Structure of Scientific Revolutions, which has been a pretty standard text for scientists for forty years. Grab a copy and read it, if you haven't-- it's a short, easy read, and gives you the broad view of how science works, and why. Why the hell I wasn't exposed to it until college, I don't know.
The program was a huge success.
As opposed to the cost of developing it yourself? If that were true, nobody would license Gamespy.
Last month, the most popular blog on my server transferred about 200MB of data (very few images on this site). 900k of that went to bloglines, which polled every hour all month long.
Yes, an ancient, alien artifact, pregnant with long-dormant, world-ravaging evil, which will no doubt unleash terrible plague and death and destruction the world over, consuming the entire human race in an unimaginable apocalypse, only possibly averted by some unlikely everyman hero who has heretofore been overlooked by society but who will, no doubt, be immortalized by his deeds on the day the evil is returned to this artifact and banished forever.
Clear as day. It's right there in the photo.
Sure, but not because I work at Sun. Like I said, I don't have anything to do with this stuff.
So, besides distributing patches to software, we can start distributing patches to licenses as well?
The provision you quoted is nothing new, and I really don't see what the big deal is. From the GPL:
counter-disclosure: I read about this on CNet, just like everyone else, and I don't know any more about this than is available at Sun's CDDL site. Also, I don't really work anywhere near the Solaris group.
The CDDL is just a refinement of the MPL-- and I've read the redline diffs, and there doesn't seem to be anything sinister or extra-restrictive about the changes.
The MPL is nice, in that it is propagative but not viral. That is, if you distribute a modified binary you have to distribute the source for your modifications, but you can use MPL-licensed code in a larger project without any effect at all on the license of the larger project.
The only reason GPL compatibility is even an issue is that there was some hope that Solaris code could be picked up and used in Linux-- which I really think was pretty optimistic. Techniques learned from the Solaris source may be transferrable, though, and I think still will be as long as the Solaris source is truly open.
Expanding suffrage to everybody does lead to better government than the alternative, which is what we call oligarchy. Of course, I define "better" as "more representative of and responsive to the people", not "in agreement with me specifically". I understand that's very trendy of me.
You seem to be fixated on the voter's verification of the receipt as the primary solution, when in fact it is simply there to enable the real solution-- recounts using physical ballots. If there are suspicious results from a precinct, you do a recount using the paper receipts that voters verified and deposited into a locked ballot box. In other words, you revert to a paper-ballot system for that precinct. It would not be a bad idea to do this for random precincts regardless of suspicion, or even to do it for all precincts all the time-- you would still have some very real benefits the machines provide (unambiguous input, multilingual displays, etc.), so it wouldn't be a wash.
I never laid this problem solely at the feet of the system manufacturers, and frankly I think you misunderstand the solution. The solution is voter-verified receipts which can be referred to after the election to cross-check the machine tallies. You'll note that I didn't say anything about open-sourcing the software. I think that's necessary, and if anything it could well lead to a false sense of security. Voting machines must always be considered and treated as untrustworthy black boxes, and their output must always be verifiable against their input. Opening the source to the software is not helpful.
You also seem to think that I want the manufacturers to pretty-please help us out here, whereas most of the people who share my views are calling for law requiring a solution like the one I described. If that law has to replace some current law that specifies the machines as they are, fine.That actually had punctuation before Slashdot stripped out the HTML entities. Sorry.
The receipt doesn't have to guarantee that the vote hasn't been tampered with. It does two things:
There must always be some record against which a vote collection and tabulation system's results can be verified. Otherwise, you have no way of knowing that something inside that black box didn't go wrong.
This is taken from a post I made a while ago to my own blog:
This machine's entire purpose in life is to count, and to count with perfect reliability. I'm a software quality engineer, and there is no way a bug of this sort would have made it past my team without all hell being raised-- and not just internally, given the product.
It's just not that hard to test a counting machine. Any freshman CS major can tell you what that machine should have done when it found it couldn't handle more votes. (Throw an error message and keep accepting votes? No.) The problems we're seeing can only be caused by extreme incompetence or by malice.
It's taking your eye off the ball to look for the problem in the operators rather than the machines and manufacturers.
Actually, it was from the Yellow Kid.
You might think of yourself as some sort of High Priest of Gizmos, but people aren't stupid. They know that if they've never heard of Ogg, they have no reason to give a damn if their gizmo can't play it.
Besides, you have to be a special kind of jackass to recommend a gizmo to someone based on its support for a format that you care about, but which you know that they don't.
Okay, so let's assume you're right and $250 is too much for most people. So what? What bearing does that have on anything at all?
This is an article about the iPod's competition, not the great mystery of why the entire population of the industrialized world hasn't bought an iPod yet.
Think about this for a minute, and assume that only Kerry, Bush, and Nader are running. Nader supporters would vote Nader/Kerry, moving from the left incrementally toward the center. Bush supporters would vote Bush/Kerry, on the same logic, and Kerry supporters would vote either Kerry/Nader (if they're left-leaning) or Kerry/Bush (if they're right-leaning).
Now, there are a hell of a lot more people who would choose Kerry or Bush as their first choice, or as their second choice, than would choose Nader at all. Result? An instant run-off would be between Bush and Kerry, and Nader would just vanish altogether. It would be as if he hadn't run.
If such were the case, Nader wouldn't even have the limited voice and influence he now does, as he could be safely ignored by the other two parties and therefore by the vast majority of the electorate.
I imagine they're the ones that respond to the poll question "who are you going to vote for?" with "Nader", and then the follow-up question "If Nader weren't in the race, who would you vote for?" with "Kerry". But I could be wrong.
Get real. The LP is not massive, and there is no conspiracy to silence and marginalize it.
Way to put words in people's mouths and then attack them over it. That's real insight, that is.
You know, I hear this a lot, even from people with the same debit card I carry. I often hear it after I tell a cashier to treat it as a credit card, from someone who's looking at me like I'm a fool who's just parted with his money.
It may be that Visa gets some money, but I don't care. It doesn't come out of my pocket.
So sayeth my bank.
More detail here, under the "Constitutional Issues" section. (References are given.)
Ah, it all becomes clear. Look, not everyone is working on telco projects "where data throughput is the most (MOST!) important parameter of the whole thing". Obviously if you're working on a project where speed trumps all, you don't want XML. My point is that such projects are in the minority, that projects which would use a message-passing protocol like XMPP are not in that minority, and that you cannot base an assessment of XML in the context of XMPP on whether or not XML is a suitable format for a low-level network protocol. XML is a suitable and very advantageous format for something like XMPP, for the reasons I've given in previous replies to your pigheaded, myopic posts.
The fact that a screwdriver didn't work for banging your nail does not mean that nobody uses screws and the screwdriver is useless in all contexts.
Those of us who do real network programming as opposed to high level toy coding , do.
Bully! That's the right tool for that job. But it is not the right tool for most jobs, and it's not necessarily the right tool for something like XMPP. Which was my whole point when you think about it, right?
This is descending into farce. I think my previous refutations of your posts are scored highly enough that people will see them, and I'm not all that interested to see whether you actually believe that all software development is throughput-centric telco software development, so I'm done. Thanks for the good times.
Fortunately, you don't have to. I provided you with a brief list later in my reply.
Thats a bit like saying you can make a go-kart go really fast if you try. Yeah great , but why not just buy a car in the first place then?
You've got your comparison backward. Your whole argument was that a car (XML), which is larger but is more versatile, wasn't as small as a go-kart (compact, binary format). My point was that if you want, you can negate the size difference while retaining the versatility of the car, so your argument is moot.
So what , its still just a shell! So you can download some parser to parse it. Oh well great, that saves a weeks development time. And slows down the whole product whenever its run. Hmm , great tradeoff. Not.
It's again clear that you've never actually developed with XML. If you really care about speed (or need to reduce memory use), you work with SAX streams instead of DOM or other object models. You might take a speed hit compared to working with byte-delimited chunks of binary data, but it will be of a scale you're certainly not going to care about in message-passing, which tends to be a sparsely executed operation anyway.
I'm also beginning to wonder whether you've actually got a job, as saving a week's development time is often the difference between whether the project gets done or not. In the context of XMPP, this could be a major factor in adoption of the protocol-- bear in mind that's a week's development time saved for every implementation of the protocol.
No , theres nothing special about "messages" that means they all have to use a standard format. Why shoehorn everything into the same dumb standard? Horses for courses...
Bear in mind that I'm talking about the messaging protocol (carrier format), not the payload. If your protocol requires changes, isn't it good to be able to add information without necessarily breaking older implementations of the protocol? Wouldn't it be good if they could simply ignore information relating to features they don't support? You can't do that in a byte-delimited binary format without careful and specific pre-planning, the effort of which may be wasted if you're not sufficiently prescient.
Absolute fastest speed and optimum compactness are not everything, and are usually pretty far down on the list of requirements even for an application-level network protocol. They are almost always trumped by minimizing development effort, maximizing extensibility and maintainability, and standards compliance (yes, even of "shells"). If this weren't the case, we'd all be writing everything in C and doing pointer math on arrays of gobbledygook all the time.
No, it's not. If you'd ever developed with XML, you'd know human-readability is not a major reason to use it.
Not only is XML bloated and so sucks up bandwidth (important if you're still on dial up) but its slow to parse and generally ugly.
XML compresses amazingly well. I have an OpenOffice spreadsheet that's 25MB in uncompressed XML. Zipped up, as OpenOffice files are, it's about 150k. That's an extreme example, but grab any xhtml web page and gzip it.
"But its for developers!" someone shouts. I'm sorry? Just how dumb a developer do you have to be to not be able to grok some efficient binary protocol? "But its a standard" someone else shouts. No it isn't. XML is a shell , you can fill it with any old shit and just because something else is "XML based" doesn't mean it will understand it.
Yes, but XML is a standard shell. Data encoded in XML can be parsed, looked up, accessed, transformed, and represented in code using off-the-shelf toolkits which are extremely good at doing all of those things. You don't have to fuck about writing a parser and a lexer, you can just grab some stuff off Jakarta and go to work on your application instead of its IO format. Furthermore, XML is extensible (that's what the X is for)... if your format requires additional information in the future, or needs to act as a carrier for another format's info, that's already taken care of. Probably a good thing for a message-passing protocol, don't you think?
Using XML for IM is a clear case of jumping on the bandwagon for no reason other than the sheep mentality coming to the fore.
Funny, my first thought when I saw your post was "oh look, another cynical-but-wise wrong-tool-for-the-job anti-XML post".