Does that translate to "owned by the big media cartels"?
I think it means, roughly, identifier vs. locator oriented, so that you ask some (presumably, nearby in network topology) server to get you a particular identified piece of content, and it does so efficiently without having to always go to the origin server and get it directly from there, unless the need to do that is inherent in the request.
HTTP/1.1 supports that quite well (including with negotiation of content types), its just a matter of having the right caches/proxies set up and using them, which is a big social problem.
P2P technologies like BitTorrent provide much of what would be needed to do this a different way that gets around the social problem, and its possible that's the route things will eventually go.
Positioning it as an extension of office is much more appealing to me than google's broadband-dependent offering.
The comparison to Outlook Web Access suggest that what they mean is that it will require a special license that is sold alongside with (or, perhaps, on top of) desktop licenses, not a local install; it will probably be no less broadband dependent than Google Apps, it will just require buying one or more desktop Office licenses in order to use.
So to the root of my diatribe, I would wager that most of the people bitching about the architects of PHP using the backslash as a name space separator could not even begin to write something like PHP and yet they feel so qualified to raise their collective voices in protest and condemn the decision of dev's who quite obviously do so
Not being able to build a car by themselves doesn't make people unable to tell that a BMW is better than a Yugo.
More to the point, "reliable" messaging is generally a reference (or euphemism, depending on your POV) for XA transaction support.
Many systems offer both, but I've seen "Reliable messaging" used for systems that offer persistent channels (usually, though IIRC not always, with transactional messaging, so that multiple interactions with the messaging system itself can be wrapped up in atomic transactions) without support for XA transactions. So I don't really think that XA is key to the general meaning of "reliable messaging", though its certainly a common feature, and certainly, as you note, important in some applications.
ZeroMQ is not really a messages broker, messages are directly sent to the recipient without passing through any broker and this is what makes ZeroMQ different and fast. But the end result is that you get the same features as a messages broker, just faster and easier.
Except, no, you don't get the features of a message broker. Particularly, you don't get reliable messaging. Its not really all that surprising that when you take the "middle" out of "middleware", you get a speed increase, at the same time losing a lot of what makes middleware useful.
This all looks like an attempt to cause confusion and muddy the waters with yet another unstandard standard.
While Microsoft's involvement may be about muddying the waters, the AMQP effort itself seems to be about actually having a standard enterprise messaging protocol: the main standard in the messaging space is XMPP, and it wasn't designed around enterprise needs (one might argue that in the long term, it would be better to adopt and/or extend XMPP, or that if you were going to design from the ground up AMQP hasn't made the right basic decisions, but that's all a little beside the point of understanding what is going on.) There are lots of implementations, but no standard protocols (several non-proprietary protocols, but that's not the same thing).
I mean, look at who was involved in this before MS signed up: its mostly big customers for enterprise messaging in the financial services industry. They've got no interest in muddying the waters. Their interest is in reducing their own costs by reducing vendor lock-in and commoditizing messaging solutions.
Bad form, perhaps, to reply twice, but for more information on what messaging is, a decent starting point is the Enterprise Integration Patterns website.
That was actually my first thought. What does this do that STOMP doesn't?
Quite a bit, actually. While its not quite at 1-0 (what every other project in the universe would call "1.0") yet (the most recent release is 0-10), you can look at the high-level requirements list for 1-0, to get an overview.
Lots of applications probably don't need what it provides over STOMP, either because they don't need it at all, or because they get it somewhere other than the basic messaging protocol, but it certainly covers a lot more than STOMP does.
The proprietary message oriented middleware (MOM) products on the market today like IBM's MQ or Tibco's Rendezvous fulfill the same function as AMQP. But they operate exclusively in single-vendor fashion and utterly fail to interoperate with each other. They are also -- perhaps not by coincidence -- burdensomely expensive.
There are also F/OSS MOM products (Apache ActiveMQ, for one) that do not operate "exclusively in single-vendor fashion" (ActiveMQ can "talk" STOMP and XMPP, as well as its native protocol, OpenWire, and of course its F/OSS), can interoperate with a number of other messaging solutions and clients, and are available without charge.
Yes, proprietary solutions are proprietary and expensive. This isn't at all unique to Message Oriented Middleware.
This is the first that I've heard of this technology. Can anyone post how this is different than XMPP (http://xmpp.org)?
AMQP seems more "enterprisey" than XMPP, focussed on traditional enterprise applications of messaging, XMPP came up from the IM world. This gives them different areas of focus, though they have considerable overlap in functionality. (There are also a number of other protocols in the messaging space: STOMP & Apache ActiveMQ's OpenWire, and most of the big commercial messaging systems use their own proprietary protocols.)
I know that every project that I get on, I try to dissuade the use of JMS (Java Message Service) and use XMPP instead.
JMS is an API, XMPP is a protocol. There are JMS implementations that can use XMPP as a transport protocol (Apache ActiveMQ, for instance, can use its native OpenWire protocol, STOMP, or XMPP).
Is this more of a competitor to the JMS spec, since it "reliable"? (whatever that means)
"Reliable" messaging usually means that once the messaging system has acknowledged receipt of the message, it has assumed responsibility for guaranteeing delivery to a suitable endpoint (possibly with some caveats). Mostly, it means in practice that the protocol or implementation provides (or, in the case of a protocol, either mandates or supports in a way which permits clients to discover whether the server is using) channels whose contents are persisted to permanent storage before they are acknowledged.
OK, I've heard people mentioning messaging and middleware, but what is this exactly? Why would I want to use this instead of XMLRPC or SOAP or something else?
Architectures using messaging are more loosely coupled than those using SOAP or XMLRPC. Essentially, every component is a messaging client, asynchronously consuming and/or producing messages that get posted to specified channels. None of the clients need to know anything about any of the other clients, only what types of messages are acceptable to be put on what channels, and what channels to listen on for types of messages they are interested in.
This makes it easier to add intermediate processing components, to scale out the number of "servers" (though they are actually a kind of clients) handling particular types of messages, etc., since multiple clients can listen on the same channels (though only one will receive each message, for a normal, queue-like channel).
Goto is not incompatible with structured programming, and contorting the Hell out a function to avoid a goto is just ritual programming without understanding.
If you have to contort the hell out of a function to avoid a goto, chances are there are bigger problems with how your function is designed; or, perhaps, you are using C. If you are using C, there are definitely places where a goto is desirable, if you are using a language with a more robust set of flow control constructs, you probably should be using them. Heck, the reason most of them exist is to provide something cleaner than gotos, for the various uses where gotos are useful when you don't have more advanced constructs.
Ultimately, its about knowing your tools: the best way to express the same fundamental logic is going to be different in an I/O bound application program written in Ruby vs. a potential processing bottleneck a computation-heavy program in C. (And if you are doing those programs with the languages reversed, your problem may be in choosing your tools in the first place.)
And by "clean-up code" I mean: you allocate resources at the top of a function, so they must be cleaned up at the bottom of the function (and no sneaky returning from the middle of the function). That code at the bottom of the function is "clean-up code". If you have 15 possible errors in your function, you either have some unreadable mess with 15 nested if statements that hide a perfectly straightforward logic flow, *or* you branch to the clean-up code in each of the 15 error cases, making the actual logic of the function obvious.
Or each of the errors raises an exception, and you have a clear structure of main flow, exception handling, and clean up using a try/catch/finally structure (or the equivalent in a language with different names, like Ruby's begin/rescue/ensure/end).
(While this has some similarity to gotos, of course, its significantly different in that the mechanism used to specify which exceptions are caught by particular handlers are more sophisticated that simple labels, and because exceptions can carry data.)
Isn't C++ supposed to be messy, hard and inelegant? Why don't we have good support for RAII in our supposedly more modern, enlightened languages?
RAII depends on the the fact that C++ uses statically allocated objects that "go out of scope". This clearly doesn't work in languages where objects are dynamically allocated and may or may not ever be destroyed. OTOH, some "more modern, enlightened" languages have fairly elegant solutions which don't rely on object lifespans, such as Ruby's (which, as I understand it, comes from Smalltalk, which predates C++) pattern:
GOTO remains the best way, in most programming languages, to exit multiple loops, branch to common clean-up code before leaving a function, etc.
In some cases, its probably the fastest way, though I'd be hesitant to call it the "best"; having loops use the right tests at the end should make it trivial to bail out of multiple loops in most cases, and having to use GOTO to get to "common cleanup code" before leaving a function is a pretty big code smell. In the usual case, the common cleanup code should just be after the loops and/or conditionals for which it is common, and the usual execution path should get you there without a GOTO. If the reason for a need to branch to common cleanup code is exception handling, try...finally or equivalent constructs are the clearest method.
Can we all agree that no one who has thought things through wants to "rent" software?
Sure, but people who have thought things through may want flexible provision of hardware resources. And with the cloud, you get that. Whether you are "renting software" depends on the software being used. If you are using a service running on open source software in the cloud, what you are paying for is support services and, effectively, hardware rental, not software rental.
Of the two challenges filed, one was voluntarily withdrawn and one was dismissed on standing; neither was decided on the merits, and so there is certainly no basis to say that "he was cleared in court".
Depending on what sort of mainframe we're talking about, the answer quite often is "...because when that existing reliable mainframe takes a lightning hit, you'll probably have to rewrite the software in a modern language to run on a modern system anyway because you won't be able to get parts to fix the ancient behemoth."
Even if you chose to replace the mainframe the COBOL ran on with another mainframe or a different kind of computer, COBOL doesn't only work on mainframes, and if you don't have backups of the system running your financial institution (as the hypothetical was framed), you have bigger problems than reimplementing the code when you have lightning strike.
The two party system evolved fairly quickly after George Washington stepped out, but it has been a bad idea implemented poorly all along.
The two-party system wasn't an "idea" that was "implemented" it was a natural consequence of winner-take all plurality (or majority-runoff) elections, and very similar systems with two dominant parties are seen almost everywhere you have that electoral model.
So now we're left with a "choice" between a man who was in the past a war hero, but currently exhibits symptoms of dementia and a man who has no past that he cares to reveal and is likely not even eligible to run for the office
If you want to be all that picky about it, McCainis actually ineligible for the same reason that conspiracy theorists claim that Obama might not have sufficiently proven eligibility, as McCain was without dispute born in the Panama Canal Zone; the Canal Zone was not at that time (or any other time) part of the United States, though it was a territory controlled by the United States.
um you should get your story straight. there are 50 separate governments within the USA
There is one government of the USA, and more than 50 separate governments in the USA (1 federal government, 50 state governments, and, beyond administrative subdivisions of states, possibly others, depending on whether one considers territories like the Commonwealth of the Northern Marianas Islands or Puerto Rico "in" the USA.)
the USA is closer to european union than to one country.
Um, no.
The US, since it is one nation, is clearly more "like" one nation than it is like any confederation of independent nations.
Sure, it has a federal government whose present structure grants the subordinate states fairly broad areas of autonomy, but then, its hardly unique among the nations of the world in having that kind of structure.
This isn't the Afghan government opressing it's citizens, it's the citizens asking the government to kill this man.
Actually, its both.
The Afghan government is, in fact, oppressing some of its own citizens, including this man. That this oppression is also popular does not stop it from being government oppression. Nor does the fact that there is a widespread support for even more extreme oppression than is being committed. Indeed, government oppression is often popular (often because the government has deliberately set up the victims of that oppression to take the blame for problems in society, or because the government has conducted the oppression as a way of winning plaudits from a society that already blames those being oppressed for problems in society), and oftentimes the mob supports even more extreme measures than those the government enacts in its oppression.
There is a reason that, e.g., America's founders did not view a popularly elected government with unlimited unauthority as a suitable safeguard of liberty, and instead set up an almost totally hamstrung government and then, when that was clearly on the road to failure from lack of sufficient authority to get things done, a more powerful but still tightly restricted government.
That schools will use this, which has no sources cited on the pages themselves, no list of authors who contributed, no history, and only the backing of the SOS peeps
The schools that will be using this, in many cases, are operated by "the SOS peeps", which is why they put it together in the first place.
With that fact in mind, suddenly it becomes less surprising that those schools would use it based on the backing of "the SOS peeps".
Didn't wikipedia just take a hit for being wildly inaccurate? I know it says they've been "checked", but checked by who? I guess its just more evidence that Americas public schools are going to just get more stupid.
SOS Children's Villages schools are not public schools nor are they, generally, America's.
Slashdot Mirror
I think it means, roughly, identifier vs. locator oriented, so that you ask some (presumably, nearby in network topology) server to get you a particular identified piece of content, and it does so efficiently without having to always go to the origin server and get it directly from there, unless the need to do that is inherent in the request.
HTTP/1.1 supports that quite well (including with negotiation of content types), its just a matter of having the right caches/proxies set up and using them, which is a big social problem.
P2P technologies like BitTorrent provide much of what would be needed to do this a different way that gets around the social problem, and its possible that's the route things will eventually go.
The comparison to Outlook Web Access suggest that what they mean is that it will require a special license that is sold alongside with (or, perhaps, on top of) desktop licenses, not a local install; it will probably be no less broadband dependent than Google Apps, it will just require buying one or more desktop Office licenses in order to use.
Not being able to build a car by themselves doesn't make people unable to tell that a BMW is better than a Yugo.
Many systems offer both, but I've seen "Reliable messaging" used for systems that offer persistent channels (usually, though IIRC not always, with transactional messaging, so that multiple interactions with the messaging system itself can be wrapped up in atomic transactions) without support for XA transactions. So I don't really think that XA is key to the general meaning of "reliable messaging", though its certainly a common feature, and certainly, as you note, important in some applications.
Except, no, you don't get the features of a message broker. Particularly, you don't get reliable messaging. Its not really all that surprising that when you take the "middle" out of "middleware", you get a speed increase, at the same time losing a lot of what makes middleware useful.
While Microsoft's involvement may be about muddying the waters, the AMQP effort itself seems to be about actually having a standard enterprise messaging protocol: the main standard in the messaging space is XMPP, and it wasn't designed around enterprise needs (one might argue that in the long term, it would be better to adopt and/or extend XMPP, or that if you were going to design from the ground up AMQP hasn't made the right basic decisions, but that's all a little beside the point of understanding what is going on.) There are lots of implementations, but no standard protocols (several non-proprietary protocols, but that's not the same thing).
I mean, look at who was involved in this before MS signed up: its mostly big customers for enterprise messaging in the financial services industry. They've got no interest in muddying the waters. Their interest is in reducing their own costs by reducing vendor lock-in and commoditizing messaging solutions.
Bad form, perhaps, to reply twice, but for more information on what messaging is, a decent starting point is the Enterprise Integration Patterns website.
Quite a bit, actually. While its not quite at 1-0 (what every other project in the universe would call "1.0") yet (the most recent release is 0-10), you can look at the high-level requirements list for 1-0, to get an overview.
Lots of applications probably don't need what it provides over STOMP, either because they don't need it at all, or because they get it somewhere other than the basic messaging protocol, but it certainly covers a lot more than STOMP does.
There are also F/OSS MOM products (Apache ActiveMQ, for one) that do not operate "exclusively in single-vendor fashion" (ActiveMQ can "talk" STOMP and XMPP, as well as its native protocol, OpenWire, and of course its F/OSS), can interoperate with a number of other messaging solutions and clients, and are available without charge.
Yes, proprietary solutions are proprietary and expensive. This isn't at all unique to Message Oriented Middleware.
XMPP, despite having originated as an IM protocol, has been used as a transport protocol for more general messaging.
AMQP seems more "enterprisey" than XMPP, focussed on traditional enterprise applications of messaging, XMPP came up from the IM world. This gives them different areas of focus, though they have considerable overlap in functionality. (There are also a number of other protocols in the messaging space: STOMP & Apache ActiveMQ's OpenWire, and most of the big commercial messaging systems use their own proprietary protocols.)
JMS is an API, XMPP is a protocol. There are JMS implementations that can use XMPP as a transport protocol (Apache ActiveMQ, for instance, can use its native OpenWire protocol, STOMP, or XMPP).
"Reliable" messaging usually means that once the messaging system has acknowledged receipt of the message, it has assumed responsibility for guaranteeing delivery to a suitable endpoint (possibly with some caveats). Mostly, it means in practice that the protocol or implementation provides (or, in the case of a protocol, either mandates or supports in a way which permits clients to discover whether the server is using) channels whose contents are persisted to permanent storage before they are acknowledged.
Architectures using messaging are more loosely coupled than those using SOAP or XMLRPC. Essentially, every component is a messaging client, asynchronously consuming and/or producing messages that get posted to specified channels. None of the clients need to know anything about any of the other clients, only what types of messages are acceptable to be put on what channels, and what channels to listen on for types of messages they are interested in.
This makes it easier to add intermediate processing components, to scale out the number of "servers" (though they are actually a kind of clients) handling particular types of messages, etc., since multiple clients can listen on the same channels (though only one will receive each message, for a normal, queue-like channel).
If you have to contort the hell out of a function to avoid a goto, chances are there are bigger problems with how your function is designed; or, perhaps, you are using C. If you are using C, there are definitely places where a goto is desirable, if you are using a language with a more robust set of flow control constructs, you probably should be using them. Heck, the reason most of them exist is to provide something cleaner than gotos, for the various uses where gotos are useful when you don't have more advanced constructs.
Ultimately, its about knowing your tools: the best way to express the same fundamental logic is going to be different in an I/O bound application program written in Ruby vs. a potential processing bottleneck a computation-heavy program in C. (And if you are doing those programs with the languages reversed, your problem may be in choosing your tools in the first place.)
This is true in approximately the same sense that a function call or return is "just another name for goto".
Or each of the errors raises an exception, and you have a clear structure of main flow, exception handling, and clean up using a try/catch/finally structure (or the equivalent in a language with different names, like Ruby's begin/rescue/ensure/end).
(While this has some similarity to gotos, of course, its significantly different in that the mechanism used to specify which exceptions are caught by particular handlers are more sophisticated that simple labels, and because exceptions can carry data.)
RAII depends on the the fact that C++ uses statically allocated objects that "go out of scope". This clearly doesn't work in languages where objects are dynamically allocated and may or may not ever be destroyed. OTOH, some "more modern, enlightened" languages have fairly elegant solutions which don't rely on object lifespans, such as Ruby's (which, as I understand it, comes from Smalltalk, which predates C++) pattern:
Resource.open(opts) do |resource|
.
.
.
end
In some cases, its probably the fastest way, though I'd be hesitant to call it the "best"; having loops use the right tests at the end should make it trivial to bail out of multiple loops in most cases, and having to use GOTO to get to "common cleanup code" before leaving a function is a pretty big code smell. In the usual case, the common cleanup code should just be after the loops and/or conditionals for which it is common, and the usual execution path should get you there without a GOTO. If the reason for a need to branch to common cleanup code is exception handling, try...finally or equivalent constructs are the clearest method.
Sure, but people who have thought things through may want flexible provision of hardware resources. And with the cloud, you get that. Whether you are "renting software" depends on the software being used. If you are using a service running on open source software in the cloud, what you are paying for is support services and, effectively, hardware rental, not software rental.
Of the two challenges filed, one was voluntarily withdrawn and one was dismissed on standing; neither was decided on the merits, and so there is certainly no basis to say that "he was cleared in court".
Even if you chose to replace the mainframe the COBOL ran on with another mainframe or a different kind of computer, COBOL doesn't only work on mainframes, and if you don't have backups of the system running your financial institution (as the hypothetical was framed), you have bigger problems than reimplementing the code when you have lightning strike.
The two-party system wasn't an "idea" that was "implemented" it was a natural consequence of winner-take all plurality (or majority-runoff) elections, and very similar systems with two dominant parties are seen almost everywhere you have that electoral model.
If you want to be all that picky about it, McCainis actually ineligible for the same reason that conspiracy theorists claim that Obama might not have sufficiently proven eligibility, as McCain was without dispute born in the Panama Canal Zone; the Canal Zone was not at that time (or any other time) part of the United States, though it was a territory controlled by the United States.
There is one government of the USA, and more than 50 separate governments in the USA (1 federal government, 50 state governments, and, beyond administrative subdivisions of states, possibly others, depending on whether one considers territories like the Commonwealth of the Northern Marianas Islands or Puerto Rico "in" the USA.)
Um, no.
The US, since it is one nation, is clearly more "like" one nation than it is like any confederation of independent nations.
Sure, it has a federal government whose present structure grants the subordinate states fairly broad areas of autonomy, but then, its hardly unique among the nations of the world in having that kind of structure.
Actually, its both.
The Afghan government is, in fact, oppressing some of its own citizens, including this man. That this oppression is also popular does not stop it from being government oppression. Nor does the fact that there is a widespread support for even more extreme oppression than is being committed. Indeed, government oppression is often popular (often because the government has deliberately set up the victims of that oppression to take the blame for problems in society, or because the government has conducted the oppression as a way of winning plaudits from a society that already blames those being oppressed for problems in society), and oftentimes the mob supports even more extreme measures than those the government enacts in its oppression.
There is a reason that, e.g., America's founders did not view a popularly elected government with unlimited unauthority as a suitable safeguard of liberty, and instead set up an almost totally hamstrung government and then, when that was clearly on the road to failure from lack of sufficient authority to get things done, a more powerful but still tightly restricted government.
The schools that will be using this, in many cases, are operated by "the SOS peeps", which is why they put it together in the first place.
With that fact in mind, suddenly it becomes less surprising that those schools would use it based on the backing of "the SOS peeps".
SOS Children's Villages schools are not public schools nor are they, generally, America's.
Talk about "wildly inaccurate"!