and I was left not knowing Java, only lame ANSI C. I got turned down for several internships for simply not knowing Java.
If you have taken CS classes and learned C (enough to know it), you must be able to easily learn any procedural or object-oriented language. If you can't, you are stupid and this is your problem.
...but it's worth to remember that "standing on the shoulders of giants" applies to anything related to the computing that actually works. One man making a big show out of making, of all things, BASIC interpreter for hardware made by others, doesn't mean that something decent can be built from scratch without serious learning and existing components.
I have seen second or third-year MIPT (Moscow Institute of Physics and Technology, in Russia) students building 8080 or Z80-based computers in 1987-89, and tweaking a lot of hardware and software in them, but I don't know if that can be really described as "from scratch" -- at that particular place there were two or three dominant base designs, with some simple "OS" written by different people, including a bunch of BASIC interpreters, editors, assembler, etc. (those things were too small to run CP/M). Making those things required mostly knowledge of electronics plus understanding of microprocessors, knowledge of 8080 instruction set, and some programming skills, not necessarily all in one person, and when I studied there I have seen, I think, about one of those things per four-people dorm room. Of course, that was in the FRTK (mostly EE) students' dorm, and at the time the most common computer that we used at the school was a russian clone of PDP-11.
Evacuating the human race from Earth won't be a realistic project for at least three or four centuries, regardless of how we go to Mars or if we even bother.
Three or four centuries that it may take assuming that science and technology will continue being developed certainly beat ten centuries of Dark Ages, that happened when development stopped. And current attitude toward development of science being measured only in the amount of money spent on overinflated prices that military/government is accustomed to paying to Boeing, Lockheed, Raytheon and their likes, can lead us to another stretch of the same thing.
Oh. So it's third-world peasants that consume increasing amount of energy, that for some reason mysteriously registers as being consumed in US. Damn energy smugglers!
then theres the problem of what is good programming? Which is better?
It's hard to define good programming, but IMHO it's pretty easy to spot most horrendously bad one -- and that would account for large enough percentage of possible union members to make the whole idea pointless.
You're already forced to follow the DMCA. It's United States law.
So is the speed limit, but it's usually unreasonable, unenforceable and hard to verify, so it comes to government/police's will to rarely and selectively enforce it. DMCA, of course, is also vague.
helped prevent World War III, brought down the Soviet Union
If it "helped prevent World War III" it certainly couldn't "bring down Soviet Union" at the same time -- those things are mutually exclusive because the only way to bring down Soviet Union using military force was World War III, that, obviously, didn't happen. In fact, none of those things happened because USSR was far beyond empire-building phase of development in 60's-80's and had no incentive to start WWIII, or any military conflict except minor ones along its borders.
Of course, you are probably one of those sheepish Americans that believe propaganda lines that Soviet Union was brought down "economically" because it couldn't pay Lockheed's and Boeing's prices for its weapons developed and built in its government-owned weapon manufacturers, an idea that is ridiculous, considering how lean was USSR military budget compared to its GNP, and how it avoided any wasteful but pointless projects such as SDI even though it had at the time better chances to put something fear-inspiring into space.
USSR was brought down by political stupidity of its rulers, with some help of American propaganda of "freedom" in libertarians' sense of word, a kind of ideology that US government keeps for "export only" and wisely avoids domestically.
All your work did was allowing US government to threaten small countries easier, and possibly killing some, most likely innocent, people.
This is exactly why unions won't work for programmers. There are too few good programmers, so instead of dealing with real issues that good programmers face, the mass of programmers, that mostly consists of lazy and stupid people, simply will be trying to get some benefits to all "programmers" -- in this case fighting against foreigners.
Will anyone here want to help some american-born javascript/asp lamer to force his employer to fire a foreign C programmer?
You see your parent post makes a perfectly reasonable point, the cost of living is very different, and you respond not with an argument, but with a slogan, you lose, your point is dead.
"Cost of living" is nothing but what people pay to others for products and services necessary for their life. Obviously, in a country that mostly consists of people enslaved by foreign businesses "cost of living" will be low because everything is produced cheaply by people who are paid poorly.
Problems start when people need something not produced/sufficiently widely available locally -- then they would have to pay at the price level that foreign company expects from its consumers, and the difference between wages in "producers" and "consumers" countries prevents "producers" from achieving quality of life available to "consumers". Since in "global economy" this situation is widespread, the poster you are answering to, makes perfectly valid point -- "global economy" with corporations operating globally, yet people confined to their poor countries, breeds poverty and abuse.
...is sufficient already, it's just its enforcement is lacking, being replaced by racketeering-style "audits" by shady organizations dressing up as a law enforcement. If some bootleggers indeed are causing problem, go after them. If some noncommercial redistribution indeed is a worthy target, sue _someone_ who does it, and try to scare others by doing so, however won't be surprised if "billions of lost revenue" will happen to be total 1000 DVDs per year for the whole country that someone might buy because he can't find a shitty DIVX copy, with the total amount of revenue insufficient to justify a single clerk writing cease and desist orders.
of Microsoft to impair competitors' software and flood courts with cases where everyone and his brother who wrote any software for Windows will sue Microsoft for losses suffered from this?
Death of company does not necessarily mean bankruptcy -- AT&T and IBM are typical dead companies that operate, yet have absolutely no attributes of their original entity, they can't and aren't trying to dominate, or even perform anything meaningful in their original area of business. Even Novell "exists".
Hardly. The US has always been an excellent source of agricultural production, much more so than say the Soviet Union in its day. Freedom yields innovation, sure. But attempts to impose order and discipline on fundamentally disordered processes yield considerably more chaos than does courteous anarchy.
Anonymous Patriots strike again -- what an idiotic example! Colombia, Argentina and Chile are even better ones regardless of their governments -- have you guys even looked at the map and checked in what latitudes most of the former Soviet Union is located? Or -- gasp -- climate zones?
Those patents never were mentioned in court -- and most likely would be declared invalid if that will happen because there is a shitload of published research that went into them.
Re:Poisoned technology again
on
Web Services
·
· Score: 2
As far as the messaging system goes, though, it's a messaging system. not a full communications package; a simple messaging system. if your problem isn't well suited to simple mmessage passing, then you shouldn't use SOAP message passing. Use something else.
I would have no problem with this statement if SOAP was designed to support some specific subset of tasks, or could be dubsivided to standards that define access to methods, data formats, etc. But the problem is, the standard is "everything or nothing" -- either one has to subscribe to all pieces of ideology that it's stuffed with, or not use it at all. And it is presented as a solution to everything -- including problems that it has nothing to do with, and can be applied to only through ugly and inefficient kludge. If standard was separated from the very beginning into data formatting, object model(s), text/non-text handling, it would be useful for everyone -- if not one part than another. But no, "standardizers" want to push the whole thing down people's throats, or declare implementations "nonstandard". This is selfish and unproductive.
If you need something more than what they can handle, just don't use them. Or use them in tandem with something more complex.
SOAP, being "everything or nothing" kind of standard can't be used in tandem with ANYTHING other than SOAP itself. It requires complete compliance and loyalty to the design on all levels. It dictates the basic protocol model, so the only way to use anything else "with" it is to support basically two distinct protocols with different data models. But if another protocol is more flexible, why would anyone use SOAP? Anything SOAP can do, can be done better by a subset of data-formatting protocol using SOAP-ish semantics over it.
web services aren't "robbing" you of anything; they're a least common denominator appropriate for *some* things.
They are certainly not the least common denominator of anything. They are arbitrarily chosen to promote certain way of using network, that, if used by someone, disallows the programmer to improve performance and design over implementations that are promoted by originators of the "standard" thus automatically making the crap made by Sun and Microsoft the best of the breed -- because everyone who will dare to improve either flexibility or performance hits the wall of what is allowed by the "standard". And beyond the "standard" there is nothing but uncharted space -- every attempt to create data formatting standard is turned into "why reinvent something, we have SOAP".
SOAP could be better; what you suggest (a bidirectional whatever) would be really neat. But i doubt it would get as popular as SOAP, becuase it's more complicated. SOAP is popular *because* it's simple.
SOAP is NOT simple, it's merely implemented, shrink-wrapped and promoted in glossy magazines as the only game in town. In fact bidirectional asynchronous transfer is easier to implement, it's just SOAP creators specifically excluded it to make the standard that promotes their narrow-minded ideas by excluding everything else -- and then they will claim that since SOAP exists and supported by "major players" while everything else is at most being developed, then SOAP should be used for everything, despite all its limitations. Software industry is only starting to recover from similar game played with Windows and their "simple" and "wonderful" Win32 API.
I suggest you try BXXP [mundi.net]. I am not sure, but it sounds like it is EXACTLY what you want. It has failed to catch on where SOAP has caught on because it is more complicated. If i am incorrect in this i apologize.
I have looked at RFC, and it has absolutely nothing to do with what I am talking about. I disagree with semantics of the messages and internal format restrictions, not their encapsulation in HTTP or TCP.
By the way, you still have not attempted to explain in any way why you dislike unicode.
I use a non-iso8859-1 language in my everyday life, therefore I don't have to explain everyone why I am qualified to decide if Unicode is good or bad. Full explanation would take many pages, and I have posted it multiple times into Unicode-related discussions, only to find out that others have no idea what I am talking about because they are happily using "Unicode" in the form of ASCII or slightly mangled iso8859-1 with their languages while I am forced into using my language in a completely screwed up way because it's not in first 256 bytes of Unicode. So here I would keep the short answer -- because I am Russian, therefore automatically qualified to make judgment about "encoding for foreigners", and I have shitload of trouble handling Russian texts with it, as opposed to any other representation of text.
you also have not attempted to offer any *alternatives* to unicode. Honestly, tell us, i am curious.
Declare byte-value transparency of protocol and remove mandatory encoding in header. If somene really needs to pass a multi-language document over XML, allow "charset" attribute everywhere where "lang" is allowed, and in the absence of charset declaration never attempt to do any language-sependent text processing. If "charset" is "UTF-8", unicode lovers will get their object of worship without forcing everyone else to do the same. Most of data that travels across the network is not designed to be directly viewed by humans, so if the creators of software do not think, charsets should be labeled for display at the time of data transfer, there should be no requirement for doing the labeling or converstion at the protocol layer. XML is created with the assumption that the primary purpose of any kind of data is to be directly displayed in a pretty-looking page, and this is what was used to justify mandatory Unicode. The problem is, declaring charset for a tag or substring is just as easy for displaying, however when the program just exchanges raw data it helps a lot if there are no arbitrary requirements for its format -- even if metadata about charset exists somewhere it may not be present, or known, when the data is being transferred, and this design decision must be respected.
Patents are easier to challenge than laws -- and the whole point of DeCSS is that it uses a different algorithm at least to the point when the key is found. And trade secrets have no legal protection at all -- it's illegal to disclose them if you are entrusted with them, but no such thing ever happened with CSS, it was reverse-engineered.
Since when does creating a backup copy of licensed material qualify as Fair Use?
License can't overturn the law, and law declares it a fair use.
Re:Poisoned technology again
on
Web Services
·
· Score: 2
XML is transparent. It's text. Granted it's unicode text. If you don't like it, use UTF-8 and play like unicode doesn't exist.
That works only with ASCII -- texts in other languages give horrendous parsing errors if processed as UTF-8, so I would have to convert it to Unicode. The problem is, most of applications aren't going to expose enough information to actually make the conversion, text may be in some charset, and charset is known on the upper level while communication happens on the lower one. And, of course, some data is just binary.
Just don't expect anybody to sympathize if you're system breaks when a Japanese company tries to use it.
That's the problem -- I want to follow standards, not invent creative ways to break them to avoid ideas they are poisoned with.
Unicode isn't a big deal to use, really. Trust me.
I am Russian. I know EVERYTHING about this "not a big deal" bullshit.
Okay, what's the difference between SOAP and a "data encapsulation standard". You do realize that SOAP isn't just RPC. You can use any XML encoding you like inside the data payload not just RPC encoding.
Data encapsulation does not assume that data is being sent to something in chunks, and then the sender expect the response or even completion. It just defines that if I want to send an array of integers, I format them in certain way. But if I want to send endless stream of structures that each contain, say, date, variable-length array of integers and three strings (what would be perfectly reasonable for, say, telemetry system on some device -- it will continue working even if it's absolutely sure that no one listening anymore), I should be able to do it without thinking that variable-length array of integers may happen to be megabytes long, and have to fit in memory for formatting or parsing.
Care for an example?
Unicode, SGML-isms in XML and RPC-ish processing.
Imagine a standard that only allows to address the service by sending HTTP-like request
I can. It's called HTTP.
No, it isn't. I have implemented HTTP, and one of possible [ab]uses of my server allows to use HTTP connection for bidirectional communication after it's established. It was a blatant violation of HTTP spec, and therefore I had to write a library that specifically disallows this if only its normal API is used.
yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization.
Granted this is difficult to do. Streaming data one direction at a time over http is easy. Streaming it both directions is not.
Both things are easy, it's just one doesn't violate the standard, and another one does. People would gain more from extending the standard for bidirectional connections than from all "standards" crap that came from Microsoft and Sun since invention of HTTP.
Can you cite an application where you'd want to stream in both directions at the same time?
Remote console over HTTP-ish proxy. X session over HTTP-ish proxy. SSH session over a HTTP-ish proxy. Typical bidirectional protocols, and they would greatly benefit from URLs as possible destinations if firewalls will interpret those URLs as proxying requests, handle authentication (in the case of X, where authentication information must be passed), etc. Access to various equipment's semi-real-time reporting and control. TV-like access to semi-time-dependent broadcast -- user infrequently sends control commands, while huge amount of streamed data is being sent to him when it's being produced by sources that he have defined in his last control request that may remain active for many days/terabytes.
In my experience, most applications need to request something then receive back a response.
Then all applications you have seen, are "embarrassingly RPC-able" (an equivalent to "embarrassingly parallelizable").
I consider unicode transparent. I have editors that work just fine with Unicode. Emacs on Unix and wordpad on Windows. If you don't want your document to have non-ascii characters in them, mark them as UTF-8 and just write them out as ASCII. Not hard. You will have problems with people trying to send you text that contains non-ASCII characters but you have that problem with ASCII. Do it like this: <xml version="1.0" encoding="UTF-8"?>
_I_ am the person who will most likely send something that is not ASCII. I don't want to be forced into a kludge that excludes even my native language from being usable, so the only alternatives I have is to slavishly follow Unicode requirement, or declare that I would rather break the standard, remove encoding from the header and consider the protocol byte-value-transparent, just like HTTP always was until some assholes started promoting their "esperanto for computers". The second alternative is looking better and better with every new "standard" issued.
You can do this with XML and SOAP. There absolutely no reason that you have to wait for the entire document to get at the data. If you're using an implementation that loads everything into a DOM before you get a whack at it, find another implementation. It's not a protocol problem.
1. The standard is specifically made in the assumption that things are "called" when the data is arrived. Streaming never "calls" anything, it may be processed in part by calling a lot of things as data is becoming available, and structure of the stream may never have an end. Is an XML document with a list that is never closed, compliant with the standard? And with infinite length?
2. There are no implementations that do that. And the requirement to "verify" XML before it's used make this impossible (BTW, what a moronic idea, to verify the format -- verify what, that sender doesn't have bugs so horrendous, they violate the standard? there is more probability that data contains complete bullshit rather than that sender formatted it wrong), but even if it's not verified, XML is made specifically to make writing compliant libraries extremely difficult, in the hope that no one would ever try to do that and will just use the implementations made by Sun and Microsoft (or expat, if they are feeling suicidal).
However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else.
That may be true. It's hard to get someone interrested in a protocol that isn't part of an existing standard.
Unless you are Sun or Microsoft.
Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.
YOU have realized it! Now it's time to make it happen. If you truely have something better, post a link to it as a reply to this message. It's great advertisement for your project and could bring you lot of new like-minded developers.
I will have to do that anyway -- my current project is cluster management, and I will have to design and implement a shitload of control/monitoring-related functionality. And no, SNMP isn't even close for being usable for that purpose, it's like umm... what would be a good example?.. oh, found, "ip over pigeons" for video streaming.
I'm dubious about your claims. That's just because I happen to like SOAP. It can be a little daunting to understand all the technologies involved in using SOAP but no more so than CORBA, DCE-RPC, SUN RPC, SMB or any other network protocol.
Understanding is easy, agreeing isn't. All protocols that you have mentioned are heavily poisoned -- why don't you use something else as an example. Say, SSL. It's just as complex, has very few working implementations, yet completely poison-free, it's made to serve its purpose, not to promote someone's way of doing things over all competing ones. Or HTTP, a protocol that is un-poisoned in 1.0, and slightly poisoned in 1.1. Or MIME. Or C language (ok, it's simpler than most of things, but its use is more complex), or C++ without the "standard" libraries. Those things are complex enough, yet they are made for goals other than excluding competing minds. And then look at all the garbage that ITU (more widely known by its former name CCITT)produced -- the purest poison that one can find in the "noosphere" -- standards all tied to each other, with complex, mind-bending and cumbersome 30-50 years old pieces pulled out of their graves to make implementations impossible, so only masochists will try to reimplement those and discover that existing implementations are buggy and incompatible with standards. Then try to honestly answer, where on the scale between those things XML and SOAP are.
I'd love to see you step up and actually post a link to a technical document that explains what you're talking about.
----- I am. Both as a profession and a hobby.
I will do that if/when I will decide to make standard base for my control/monitoring applications. If I will get nearly as much shit from "standards makers" as when I tried to prevent mandatory-Unicode-fication of FTP (yes, there was a draft about that, I have no idea if it ever made into RFC, but in either case no one ever tried to implement that), I would be content with keeping the protocol "published-proprietary", a standard specific for the product. But what I am certainly not going to do is to use SOAP or other XML-RPC-isms as an internal protocol.
Poisoned technology again
on
Web Services
·
· Score: 2
"Web services standards" are robbing network programming from its greatest advantages -- possibility of asynchronous processing, data transparency and flexibility in the data models. Programmers don't neet SOAP or RPC of any kind, they need data encapsulation standard, and one that is not tied to poisoned technology such as XML, Unicode ot Java (yes, those are "open standards", but they are stuffed with idiosyncrasy of their developers and therefore promote all kinds of ideas, in my opinion, stupid ones, over other ideas that are superior for a lot of applications, yet excluded and made impossible to implement over narrow-minded standards).
Imagine a standard that only allows to address the service by sending HTTP-like request, yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization. Imagine "document" that is just like XML, but without all the Unicode crap (data is transparent -- if one wants to use unicode, mark it as unicode, and make software aware of it, otherwise just don't), without end of document, so data can be streamed endlessly and become available as the tags/fields are parsed.
This would be far superior for any imaginable purpose to all those little "standards" that Microsoft and Sun originate, and W3C ruberstamps by dozens, that would be a truly useful tool that will improve network programming. However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else. Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.
As one of the most noticeable examples -- Taiwan. For all practical purposes it's a politically, economically and even military dependent country, even though it's formally a part of a completely different (and not exactly friendly to the US) other country. But this is an example of a colony that has relativaly little problems with being a colony. Really, and more important, most of countries in southeast asia, africa and latin america that US (and IMF as its tool) force into economical dependence, so just get a list of countries with a large IMF debt per capita, and that would be them -- some of them can't even grow enough food because they can only pay interest on IMF "debts" by planting coffee on most of agricultural land that they have. They have entirely export-oriented economy, with most of stuff owned by american and other international corporations, that run most of those "economies" for their benefit -- governments are too weak and/or corrupt to mandate something produced to remain in the country, so country becomes a larger version of lower-class/industrial neighborhood where people work a lot and consume what their salary can afford, while US becomes an equivalent of a rich one that consumes the products and controls the flow of money. Except that there is a bunch of national borders between them.
Formally they are not colonies, but this doesn't change the situation -- most of wars in last half a century aren't being formally declared either, yet no one denies their existence.
Slashdot Mirror
I completely agree with people that ridiculed you.
and I was left not knowing Java, only lame ANSI C. I got turned down for several internships for simply not knowing Java.
If you have taken CS classes and learned C (enough to know it), you must be able to easily learn any procedural or object-oriented language. If you can't, you are stupid and this is your problem.
...but it's worth to remember that "standing on the shoulders of giants" applies to anything related to the computing that actually works. One man making a big show out of making, of all things, BASIC interpreter for hardware made by others, doesn't mean that something decent can be built from scratch without serious learning and existing components.
I have seen second or third-year MIPT (Moscow Institute of Physics and Technology, in Russia) students building 8080 or Z80-based computers in 1987-89, and tweaking a lot of hardware and software in them, but I don't know if that can be really described as "from scratch" -- at that particular place there were two or three dominant base designs, with some simple "OS" written by different people, including a bunch of BASIC interpreters, editors, assembler, etc. (those things were too small to run CP/M). Making those things required mostly knowledge of electronics plus understanding of microprocessors, knowledge of 8080 instruction set, and some programming skills, not necessarily all in one person, and when I studied there I have seen, I think, about one of those things per four-people dorm room. Of course, that was in the FRTK (mostly EE) students' dorm, and at the time the most common computer that we used at the school was a russian clone of PDP-11.
Evacuating the human race from Earth won't be a realistic project for at least three or four centuries, regardless of how we go to Mars or if we even bother.
Three or four centuries that it may take assuming that science and technology will continue being developed certainly beat ten centuries of Dark Ages, that happened when development stopped. And current attitude toward development of science being measured only in the amount of money spent on overinflated prices that military/government is accustomed to paying to Boeing, Lockheed, Raytheon and their likes, can lead us to another stretch of the same thing.
Oh. So it's third-world peasants that consume increasing amount of energy, that for some reason mysteriously registers as being consumed in US. Damn energy smugglers!
I am 32, and SOAP still sucks.
then theres the problem of what is good programming? Which is better?
It's hard to define good programming, but IMHO it's pretty easy to spot most horrendously bad one -- and that would account for large enough percentage of possible union members to make the whole idea pointless.
You're already forced to follow the DMCA. It's United States law.
So is the speed limit, but it's usually unreasonable, unenforceable and hard to verify, so it comes to government/police's will to rarely and selectively enforce it. DMCA, of course, is also vague.
helped prevent World War III, brought down the Soviet Union
If it "helped prevent World War III" it certainly couldn't "bring down Soviet Union" at the same time -- those things are mutually exclusive because the only way to bring down Soviet Union using military force was World War III, that, obviously, didn't happen. In fact, none of those things happened because USSR was far beyond empire-building phase of development in 60's-80's and had no incentive to start WWIII, or any military conflict except minor ones along its borders.
Of course, you are probably one of those sheepish Americans that believe propaganda lines that Soviet Union was brought down "economically" because it couldn't pay Lockheed's and Boeing's prices for its weapons developed and built in its government-owned weapon manufacturers, an idea that is ridiculous, considering how lean was USSR military budget compared to its GNP, and how it avoided any wasteful but pointless projects such as SDI even though it had at the time better chances to put something fear-inspiring into space.
USSR was brought down by political stupidity of its rulers, with some help of American propaganda of "freedom" in libertarians' sense of word, a kind of ideology that US government keeps for "export only" and wisely avoids domestically.
All your work did was allowing US government to threaten small countries easier, and possibly killing some, most likely innocent, people.
This is exactly why unions won't work for programmers. There are too few good programmers, so instead of dealing with real issues that good programmers face, the mass of programmers, that mostly consists of lazy and stupid people, simply will be trying to get some benefits to all "programmers" -- in this case fighting against foreigners.
Will anyone here want to help some american-born javascript/asp lamer to force his employer to fire a foreign C programmer?
Pop quiz: How many factories are there in Indonesia with better working conditions?
"...But your honor, all other murder victims I have heard of, are dead, too!"
You see your parent post makes a perfectly reasonable point, the cost of living is very different, and you respond not with an argument, but with a slogan, you lose, your point is dead.
"Cost of living" is nothing but what people pay to others for products and services necessary for their life. Obviously, in a country that mostly consists of people enslaved by foreign businesses "cost of living" will be low because everything is produced cheaply by people who are paid poorly.
Problems start when people need something not produced/sufficiently widely available locally -- then they would have to pay at the price level that foreign company expects from its consumers, and the difference between wages in "producers" and "consumers" countries prevents "producers" from achieving quality of life available to "consumers". Since in "global economy" this situation is widespread, the poster you are answering to, makes perfectly valid point -- "global economy" with corporations operating globally, yet people confined to their poor countries, breeds poverty and abuse.
DIVX copy
...of course, proper spelling is "Divx ;-)"
...is sufficient already, it's just its enforcement is lacking, being replaced by racketeering-style "audits" by shady organizations dressing up as a law enforcement. If some bootleggers indeed are causing problem, go after them. If some noncommercial redistribution indeed is a worthy target, sue _someone_ who does it, and try to scare others by doing so, however won't be surprised if "billions of lost revenue" will happen to be total 1000 DVDs per year for the whole country that someone might buy because he can't find a shitty DIVX copy, with the total amount of revenue insufficient to justify a single clerk writing cease and desist orders.
of Microsoft to impair competitors' software and flood courts with cases where everyone and his brother who wrote any software for Windows will sue Microsoft for losses suffered from this?
It's hard to sell office PCs at loss.
Death of company does not necessarily mean bankruptcy -- AT&T and IBM are typical dead companies that operate, yet have absolutely no attributes of their original entity, they can't and aren't trying to dominate, or even perform anything meaningful in their original area of business. Even Novell "exists".
Hardly. The US has always been an excellent source of agricultural production, much more so than say the Soviet Union in its day. Freedom yields innovation, sure. But attempts to impose order and discipline on fundamentally disordered processes yield considerably more chaos than does courteous anarchy.
Anonymous Patriots strike again -- what an idiotic example! Colombia, Argentina and Chile are even better ones regardless of their governments -- have you guys even looked at the map and checked in what latitudes most of the former Soviet Union is located? Or -- gasp -- climate zones?
Those patents never were mentioned in court -- and most likely would be declared invalid if that will happen because there is a shitload of published research that went into them.
As far as the messaging system goes, though, it's a messaging system. not a full communications package; a simple messaging system. if your problem isn't well suited to simple mmessage passing, then you shouldn't use SOAP message passing. Use something else.
I would have no problem with this statement if SOAP was designed to support some specific subset of tasks, or could be dubsivided to standards that define access to methods, data formats, etc. But the problem is, the standard is "everything or nothing" -- either one has to subscribe to all pieces of ideology that it's stuffed with, or not use it at all. And it is presented as a solution to everything -- including problems that it has nothing to do with, and can be applied to only through ugly and inefficient kludge. If standard was separated from the very beginning into data formatting, object model(s), text/non-text handling, it would be useful for everyone -- if not one part than another. But no, "standardizers" want to push the whole thing down people's throats, or declare implementations "nonstandard". This is selfish and unproductive.
If you need something more than what they can handle, just don't use them. Or use them in tandem with something more complex.
SOAP, being "everything or nothing" kind of standard can't be used in tandem with ANYTHING other than SOAP itself. It requires complete compliance and loyalty to the design on all levels. It dictates the basic protocol model, so the only way to use anything else "with" it is to support basically two distinct protocols with different data models. But if another protocol is more flexible, why would anyone use SOAP? Anything SOAP can do, can be done better by a subset of data-formatting protocol using SOAP-ish semantics over it.
web services aren't "robbing" you of anything; they're a least common denominator appropriate for *some* things.
They are certainly not the least common denominator of anything. They are arbitrarily chosen to promote certain way of using network, that, if used by someone, disallows the programmer to improve performance and design over implementations that are promoted by originators of the "standard" thus automatically making the crap made by Sun and Microsoft the best of the breed -- because everyone who will dare to improve either flexibility or performance hits the wall of what is allowed by the "standard". And beyond the "standard" there is nothing but uncharted space -- every attempt to create data formatting standard is turned into "why reinvent something, we have SOAP".
SOAP could be better; what you suggest (a bidirectional whatever) would be really neat. But i doubt it would get as popular as SOAP, becuase it's more complicated. SOAP is popular *because* it's simple.
SOAP is NOT simple, it's merely implemented, shrink-wrapped and promoted in glossy magazines as the only game in town. In fact bidirectional asynchronous transfer is easier to implement, it's just SOAP creators specifically excluded it to make the standard that promotes their narrow-minded ideas by excluding everything else -- and then they will claim that since SOAP exists and supported by "major players" while everything else is at most being developed, then SOAP should be used for everything, despite all its limitations. Software industry is only starting to recover from similar game played with Windows and their "simple" and "wonderful" Win32 API.
I suggest you try BXXP [mundi.net]. I am not sure, but it sounds like it is EXACTLY what you want. It has failed to catch on where SOAP has caught on because it is more complicated. If i am incorrect in this i apologize.
I have looked at RFC, and it has absolutely nothing to do with what I am talking about. I disagree with semantics of the messages and internal format restrictions, not their encapsulation in HTTP or TCP.
By the way, you still have not attempted to explain in any way why you dislike unicode.
I use a non-iso8859-1 language in my everyday life, therefore I don't have to explain everyone why I am qualified to decide if Unicode is good or bad. Full explanation would take many pages, and I have posted it multiple times into Unicode-related discussions, only to find out that others have no idea what I am talking about because they are happily using "Unicode" in the form of ASCII or slightly mangled iso8859-1 with their languages while I am forced into using my language in a completely screwed up way because it's not in first 256 bytes of Unicode. So here I would keep the short answer -- because I am Russian, therefore automatically qualified to make judgment about "encoding for foreigners", and I have shitload of trouble handling Russian texts with it, as opposed to any other representation of text.
you also have not attempted to offer any *alternatives* to unicode. Honestly, tell us, i am curious.
Declare byte-value transparency of protocol and remove mandatory encoding in header. If somene really needs to pass a multi-language document over XML, allow "charset" attribute everywhere where "lang" is allowed, and in the absence of charset declaration never attempt to do any language-sependent text processing. If "charset" is "UTF-8", unicode lovers will get their object of worship without forcing everyone else to do the same. Most of data that travels across the network is not designed to be directly viewed by humans, so if the creators of software do not think, charsets should be labeled for display at the time of data transfer, there should be no requirement for doing the labeling or converstion at the protocol layer. XML is created with the assumption that the primary purpose of any kind of data is to be directly displayed in a pretty-looking page, and this is what was used to justify mandatory Unicode. The problem is, declaring charset for a tag or substring is just as easy for displaying, however when the program just exchanges raw data it helps a lot if there are no arbitrary requirements for its format -- even if metadata about charset exists somewhere it may not be present, or known, when the data is being transferred, and this design decision must be respected.
Patents are easier to challenge than laws -- and the whole point of DeCSS is that it uses a different algorithm at least to the point when the key is found. And trade secrets have no legal protection at all -- it's illegal to disclose them if you are entrusted with them, but no such thing ever happened with CSS, it was reverse-engineered.
Since when does creating a backup copy of licensed material qualify as Fair Use?
License can't overturn the law, and law declares it a fair use.
XML is transparent. It's text. Granted it's unicode text. If you don't like it, use UTF-8 and play like unicode doesn't exist.
That works only with ASCII -- texts in other languages give horrendous parsing errors if processed as UTF-8, so I would have to convert it to Unicode. The problem is, most of applications aren't going to expose enough information to actually make the conversion, text may be in some charset, and charset is known on the upper level while communication happens on the lower one. And, of course, some data is just binary.
Just don't expect anybody to sympathize if you're system breaks when a Japanese company tries to use it.
That's the problem -- I want to follow standards, not invent creative ways to break them to avoid ideas they are poisoned with.
Unicode isn't a big deal to use, really. Trust me.
I am Russian. I know EVERYTHING about this "not a big deal" bullshit.
Okay, what's the difference between SOAP and a "data encapsulation standard". You do realize that SOAP isn't just RPC. You can use any XML encoding you like inside the data payload not just RPC encoding.
Data encapsulation does not assume that data is being sent to something in chunks, and then the sender expect the response or even completion. It just defines that if I want to send an array of integers, I format them in certain way. But if I want to send endless stream of structures that each contain, say, date, variable-length array of integers and three strings (what would be perfectly reasonable for, say, telemetry system on some device -- it will continue working even if it's absolutely sure that no one listening anymore), I should be able to do it without thinking that variable-length array of integers may happen to be megabytes long, and have to fit in memory for formatting or parsing.
Care for an example?
Unicode, SGML-isms in XML and RPC-ish processing.
Imagine a standard that only allows to address the service by sending HTTP-like request
I can. It's called HTTP.
No, it isn't. I have implemented HTTP, and one of possible [ab]uses of my server allows to use HTTP connection for bidirectional communication after it's established. It was a blatant violation of HTTP spec, and therefore I had to write a library that specifically disallows this if only its normal API is used.
yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization.
Granted this is difficult to do. Streaming data one direction at a time over http is easy. Streaming it both directions is not.
Both things are easy, it's just one doesn't violate the standard, and another one does. People would gain more from extending the standard for bidirectional connections than from all "standards" crap that came from Microsoft and Sun since invention of HTTP.
Can you cite an application where you'd want to stream in both directions at the same time?
Remote console over HTTP-ish proxy. X session over HTTP-ish proxy. SSH session over a HTTP-ish proxy. Typical bidirectional protocols, and they would greatly benefit from URLs as possible destinations if firewalls will interpret those URLs as proxying requests, handle authentication (in the case of X, where authentication information must be passed), etc. Access to various equipment's semi-real-time reporting and control. TV-like access to semi-time-dependent broadcast -- user infrequently sends control commands, while huge amount of streamed data is being sent to him when it's being produced by sources that he have defined in his last control request that may remain active for many days/terabytes.
In my experience, most applications need to request something then receive back a response.
Then all applications you have seen, are "embarrassingly RPC-able" (an equivalent to "embarrassingly parallelizable").
I consider unicode transparent. I have editors that work just fine with Unicode. Emacs on Unix and wordpad on Windows. If you don't want your document to have non-ascii characters in them, mark them as UTF-8 and just write them out as ASCII. Not hard. You will have problems with people trying to send you text that contains non-ASCII characters but you have that problem with ASCII. Do it like this: <xml version="1.0" encoding="UTF-8"?>
_I_ am the person who will most likely send something that is not ASCII. I don't want to be forced into a kludge that excludes even my native language from being usable, so the only alternatives I have is to slavishly follow Unicode requirement, or declare that I would rather break the standard, remove encoding from the header and consider the protocol byte-value-transparent, just like HTTP always was until some assholes started promoting their "esperanto for computers". The second alternative is looking better and better with every new "standard" issued.
You can do this with XML and SOAP. There absolutely no reason that you have to wait for the entire document to get at the data. If you're using an implementation that loads everything into a DOM before you get a whack at it, find another implementation. It's not a protocol problem.
1. The standard is specifically made in the assumption that things are "called" when the data is arrived. Streaming never "calls" anything, it may be processed in part by calling a lot of things as data is becoming available, and structure of the stream may never have an end. Is an XML document with a list that is never closed, compliant with the standard? And with infinite length?
2. There are no implementations that do that. And the requirement to "verify" XML before it's used make this impossible (BTW, what a moronic idea, to verify the format -- verify what, that sender doesn't have bugs so horrendous, they violate the standard? there is more probability that data contains complete bullshit rather than that sender formatted it wrong), but even if it's not verified, XML is made specifically to make writing compliant libraries extremely difficult, in the hope that no one would ever try to do that and will just use the implementations made by Sun and Microsoft (or expat, if they are feeling suicidal).
However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else.
That may be true. It's hard to get someone interrested in a protocol that isn't part of an existing standard.
Unless you are Sun or Microsoft.
Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.
YOU have realized it! Now it's time to make it happen. If you truely have something better, post a link to it as a reply to this message. It's great advertisement for your project and could bring you lot of new like-minded developers.
I will have to do that anyway -- my current project is cluster management, and I will have to design and implement a shitload of control/monitoring-related functionality. And no, SNMP isn't even close for being usable for that purpose, it's like umm... what would be a good example?.. oh, found, "ip over pigeons" for video streaming.
I'm dubious about your claims. That's just because I happen to like SOAP. It can be a little daunting to understand all the technologies involved in using SOAP but no more so than CORBA, DCE-RPC, SUN RPC, SMB or any other network protocol.
Understanding is easy, agreeing isn't. All protocols that you have mentioned are heavily poisoned -- why don't you use something else as an example. Say, SSL. It's just as complex, has very few working implementations, yet completely poison-free, it's made to serve its purpose, not to promote someone's way of doing things over all competing ones. Or HTTP, a protocol that is un-poisoned in 1.0, and slightly poisoned in 1.1. Or MIME. Or C language (ok, it's simpler than most of things, but its use is more complex), or C++ without the "standard" libraries. Those things are complex enough, yet they are made for goals other than excluding competing minds. And then look at all the garbage that ITU (more widely known by its former name CCITT)produced -- the purest poison that one can find in the "noosphere" -- standards all tied to each other, with complex, mind-bending and cumbersome 30-50 years old pieces pulled out of their graves to make implementations impossible, so only masochists will try to reimplement those and discover that existing implementations are buggy and incompatible with standards. Then try to honestly answer, where on the scale between those things XML and SOAP are.
I'd love to see you step up and actually post a link to a technical document that explains what you're talking about. ----- I am. Both as a profession and a hobby.
I will do that if/when I will decide to make standard base for my control/monitoring applications. If I will get nearly as much shit from "standards makers" as when I tried to prevent mandatory-Unicode-fication of FTP (yes, there was a draft about that, I have no idea if it ever made into RFC, but in either case no one ever tried to implement that), I would be content with keeping the protocol "published-proprietary", a standard specific for the product. But what I am certainly not going to do is to use SOAP or other XML-RPC-isms as an internal protocol.
"Web services standards" are robbing network programming from its greatest advantages -- possibility of asynchronous processing, data transparency and flexibility in the data models. Programmers don't neet SOAP or RPC of any kind, they need data encapsulation standard, and one that is not tied to poisoned technology such as XML, Unicode ot Java (yes, those are "open standards", but they are stuffed with idiosyncrasy of their developers and therefore promote all kinds of ideas, in my opinion, stupid ones, over other ideas that are superior for a lot of applications, yet excluded and made impossible to implement over narrow-minded standards).
Imagine a standard that only allows to address the service by sending HTTP-like request, yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization. Imagine "document" that is just like XML, but without all the Unicode crap (data is transparent -- if one wants to use unicode, mark it as unicode, and make software aware of it, otherwise just don't), without end of document, so data can be streamed endlessly and become available as the tags/fields are parsed.
This would be far superior for any imaginable purpose to all those little "standards" that Microsoft and Sun originate, and W3C ruberstamps by dozens, that would be a truly useful tool that will improve network programming. However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else. Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.
As one of the most noticeable examples -- Taiwan. For all practical purposes it's a politically, economically and even military dependent country, even though it's formally a part of a completely different (and not exactly friendly to the US) other country. But this is an example of a colony that has relativaly little problems with being a colony. Really, and more important, most of countries in southeast asia, africa and latin america that US (and IMF as its tool) force into economical dependence, so just get a list of countries with a large IMF debt per capita, and that would be them -- some of them can't even grow enough food because they can only pay interest on IMF "debts" by planting coffee on most of agricultural land that they have. They have entirely export-oriented economy, with most of stuff owned by american and other international corporations, that run most of those "economies" for their benefit -- governments are too weak and/or corrupt to mandate something produced to remain in the country, so country becomes a larger version of lower-class/industrial neighborhood where people work a lot and consume what their salary can afford, while US becomes an equivalent of a rich one that consumes the products and controls the flow of money. Except that there is a bunch of national borders between them.
Formally they are not colonies, but this doesn't change the situation -- most of wars in last half a century aren't being formally declared either, yet no one denies their existence.