Give us an incentive to buy your CDs and we'll buy it. Stop blatently rip us off!
Let me get this straight. You think that CDs are too expensive, therefore the RIAA is ripping you off. So you take music from the publishers (and, indirectly, from the RIAA) without paying for it, and this is okay.
Wait. I must have missed something.
Re:This is what they should do, but still won't wo
on
RIAA to Sue You Now
·
· Score: 2
The RIAA has tried (successfully) to paint P2P networks as festering cesspools of piracy and other sorts of illegal activity.
Log on to one of them and do a search for something random. Count the number of legitimate files you see-- meaning files that can be shared without breaking any contracts, rules, or laws-- and compare to the number of illegitimate files you see-- meaning files that shouldn't be shared. That ratio makes it pretty tough to call P2P networks anything other than festering cesspools of piracy.
Have you ever stopped to consider, through all of your knee-jerk reactions and unlikely political opinions, that the RIAA and the MPAA might actually have a point?
Companies like the RIAA and the MPAA are going to go out of business. Period. When people have the ability to make an infinite number of copies of your product, at virtually no cost, you can't make money anymore. It's as simple as that.
Then you'd better hang on tight to your favorite music and movies. Because there won't be much more of 'em. Music and movies aren't cheap to produce. Somebody has to put up the cash to get 'em made. Even though the artists themselves may not care about getting rich-- I'm sure some of them don't-- they're going to have to get funded somehow. If nobody believes they can make a profit by investing in a new movie, then nobody will do it, and the movie won't get made. No more 2001s. No more Citizen Kanes. No more.
Of course, I think your line of argument is full of shit, so I'm really not all that nervous.
In the eyes of publishers, libraries are nothing but open copyright violations. All the arguments being made about "piracy" apply directly to libraries.
Can you post one single source for this information? One out-of-context quote from an exec at Random House? Anything?
No personal offense intended, but your post sounded pretty made-up. I'm not accusing you of anything; I'd just like to know where you get these unusual ideas.
What business model follows naturally from relational databases?
You're kidding, right? Maintaining large sets of textual information is one of the oldest problems. Companies expend a metric assload of time and effort managing their information stores, from accounting to inventory to HR and on and on. Relational databases, with a few additional bits like form builders and report generators, let companies do that more efficiently. Instant ROI. That's a really clear business case.
What business model follows naturally from C++?
That's admittedly harder to define, but C++ is more abstract than web services technology is. Web services technology is, fundamentally, about exchanging information or commands between two applications over a TCP socket. Everything else is just the specifics of the standard(s). This naturally raises the question, ``Why do you want to exchange data or commands?'' To this question, there are lots of answers. But I can't readily think of a situation in which we need to exchange data or commands between two computers or two programs but can't yet because we don't have a technology for doing so. So the real question behind web services is this: ``What am I doing right now that can be significantly improved with web services technology, in some way that increases my efficiency, or that directly generates a profit for me?''
The direct route would be to use web services technology to offer new services for sale to customers. We've already beaten that dead horse; the bottom line is that companies aren't really rushing to offer for-pay services based on these new technologies.
The indirect route is what we're really talking about here. What can web services technology give me that will improve the way I do business and help me make more money? All of the examples you gave, ``integrate legacy systems, purchase syndicated content (like a Reuter's feed) in a standardized form, lower the cost of EDI and get more partners into the EDI game, etc,'' are already being done on large scales with other technologies. So one is left wondering how, exactly, web services technology will help anybody do those things better than they're currently doing them.
That's what I'm getting at. If an employee came to me and said, ``Let's deploy web services!'' I'd have to ask why. What potential gain can justify the expense and effort required to deploy that kind of technology in place of some other technology that we're already using now.
I guess I just don't see the problem that web services technology is trying to solve.
Damn IE! I was halfway through my post when somehow the focus shifted without my knowing it. I hit the ``delete'' key, and my browser went back one page. Damn!
People will pay for good products, no matter where or how they are made available.
While your statement sounds reasonable enough, I'm not sure we can jump to that conclusion. Can you name one non-informational content company that has broken even or made a profit selling their content through the Internet? By saying ``non-informational'' I mean to exclude companies like WestLaw; their business model is very clear and very solid. But I'm talking about content for which there isn't a fixed demand, like news or entertainment information for the mass market.
Companies like Conde Nast make a decent profit (as far as I know) publishing and selling magazines. Has there been any similar venture that has used the Internet as a delivery channel?
Ever considered combining PHP with C-based CGI?[...] Is that sort of solution unrealistic in the enterprise environment?
In my opinion, it is. For starters, writing CGI applications in C is painful and error-prone. Java servlets are faster and much easier to write cleanly. So there's no real reason to use C or C++-language CGI for anything, unless you're doing something tricky on the back end that just can't be done with Java.
On the other side of the coin, we've got PHP. PHP is easier to write and faster to develop than JSP, in my opinion, but harder to write in any sort of scalable way. For instance, JSP gives you tag libraries which can be used to abstract out some Java code without having to delve all the way into servlets. Very handy for presentation-layer automation. PHP doesn't give you that.
There are lots of little things, too. You can package up an entire web app into a couple of files, for instance, while deploying a PHP/CGI application requires the installation of a whole tree full of scripts and programs. A small thing, but it makes a difference in the long haul.
So I think the combination of PHP and CGI is better than PHP alone, but still losing in comparison to J2EE technolgies.
Any application can use the SOAP protocol to communicate with their server instead of proprietary binary, text, or XML formats; multi-tier architectures will increasingly use SOAP to communicate; etc.
What proprietary formats are you thinking of? CORBA is the opposite of proprietary, and it works very well. If you apply web services technologies to problems that are currently being solved with CORBA applications, you may find that the web services version is, at best, no better than the CORBA version.
I suppose one might argue that web services technologies are better suited to the high-latency environment of the internet, but I don't necessarily buy that. I run CORBA applications across the internet from home to office and vice-versa all the time, with no complaints.
Just like text, TCP/IP, HTTP, and XML, SOAP standardizes how computers talk to each other.
So does CORBA. So we have two competing implementations of the same basic idea. Question is, is SOAP better in any significant way? I haven't yet seen anything that says it is. In fact, the amount of effort required to marshall and de-marshall objects into XML seems prohibitive in a lot of situations. CORBA obviates that need through the standardized mappings of IDL constructs to native language types.
Second, the original poster argued that there is no *problem domain* for Web services.
Just for the record, no I didn't. (And neither did the guy above me. I'm not 100% sure who you're calling ``original'' here.)
The guy above me said that there's no demand for web services implementations or applications. I said there's no business model for using them, either. You pointed out that there are software-to-software applications for web services technologies that I hadn't thought of, which I concede, but I'm still not sure that means there's a B-to-B or B-to-C business model that requires them.
Note that I'm not talking about the same thing you're talking about. You're talking about problem spaces. What can we use web services technologies for? I'm talking about business cases. What can we do with web services that will either be profitable by itself, or enhance our profitability in some indirect way? These are two really different things.
Often technologies fail not because they themselves are inferior, or because nobody understands how they could use them. They often fail because nobody understands why they should use them.
Salon did $1.1M selling subscriptions with over 30,000 sales. Sounds successful to me. Now, because they SPENT $75 million, doesn't mean that people "won't pay for content." (Web myth #47)
First of all, it's pretty silly of you to jump from my ``charging for content hasn't been a successful business model'' to ``people won't pay for content.'' These are two entirely different things.
But besides that, I'd say Salon's situation proves my point, not disproves it. Selling subscriptions hasn't helped them break even, so that model has, so far, not succeeded. That's the goal of a business model, after all: to either enable you to break even, or, preferably, make a profit. Salon hasn't done that. QED.
All of this is being written, by the way, by a guy who signed up for a Salon Premium subscription over a year ago.
(Uh-oh. OSQ coming on. Homer: ``Would you look at those morons... I paid my taxes over a year ago!'')
So, you see, the body of evidence available to us would suggest that the idea that the idea that people won't pay for content is a myth is, in fact, a myth. ("Huh?") Most businesses that have tried to turn pay-for-content into a profitable revenue model have failed to do so. So while it's not literally true that people won't pay for content under any circumstances, it's thus far been true that people won't pay in sufficient numbers or at sufficiently high rates to make selling content a profitable enterprise.
Then compare them both [PHP, JSP] with XSP - the choice is obviously for XSP.
Unless, if course, you want to be able to read your code.
I'm astounded by people who think XML is an acceptable language for writing code or documents. Just as writing in pure HTML is only for the gearest of the gearheads (myself included), writing pure XML, or XML with embedded logic like XSP, is painful in the extreme.
It's really getting to the point where XML and its derivatives are write-only formats, suitable for machine-to-machine communication only. Hell, even Ant pisses me off with its XML syntax for makefiles. I miss make.:-(
So I just lean that way since it works so well for us so often. It is very easy to get into habits. It is good to hear other ways of doing something so that one does not get too entrenched in a single approach.
Now that's refreshing. All too often, GUI programmers were raised on the Mac Way, or (worse) the Windows Way, or (even worse) the Java Way, and they spend all of their time trying to shave the corners off of square pegs. What's worst of all, of course, is when your customer is entrenched in the Windows Way, and mandates the use of tabbed dialog boxes for data entry interfaces, then complains when the app is slow and hard to use.
You see before we had GUIs, and windows, next feild was always Enter. While tab seems to work in text/word processing, keypunch entry is another matter.
Ah, but I'm talking about a system even older than that. I'm talking about an IBM mainframe system with dumb terminals attached over serial lines. The mainframe sends you a screen, and you use the terminal to navigate through the fields and input data. Then you send the entire screen of data back to the mainframe for processing. It's not an interactive system. It's almost a batch processing system, except that you process each screen as you're done with it.
That's why the ``enter'' key couldn't be used for advance-to-next-field, because ``enter'' had to be used for process-this-screen-now.
That said, I'm sure you're right that ``tab'' is a bad thing if you spend all your time on the numeric keypad. But the kind of applications I'm thinking of were text-based, not number-based, so to those operators ``tab'' made more sense anyway.
I think you're kind of overstating your point to say, ``I have seen no benefit except confusion to the tab.'' It's more a case of one being better than the other in each situation.
There is really no comparison with browser based apps. Web services are for solving problems that cannot be solved with browser based apps because they do not involve human interaction. You cannot integrate CRM and accounting systems with a browser-based app.
Okay, that's a good point. I was only thinking of using web services protocols for connecting desktop applications to server applications. Connecting two server applications together with web services makes a lot more sense. Thanks for the clarification.
Data Entry Errors- large. The more freedom the user has- the more ways they will mess it up.
I suppose that's a valid point, but it falls to the application designers to put in all reasonable checks on input. You can't verify that a last name was spelled correctly, of course, but there's no way to guarantee that in the UI either. But for things like entering codes for medical billing (a huge, vast data processing job that most people aren't even aware of) you can put a good deal of sanity checking in the back-end system to minimize errors. You can't eliminate them, but you can cut 'em down quite a bit if your application is clever enough. For example, the system will initally reject a billing record that includes no surgical procedures, two nights in a room, and only five meals. The system knows that most non-surgical patients get fed three times a day, every day. If the patient had a surgical procedure, the system will accept the record, because it knows that surgical patients are always NPO for part of their stay. (Oh, NPO = ``nil per os,'' or ``nothing by mouth,'' meaning no food or drink.)
But like all things, it's a trade off. The hospital would have had a much bigger problem if every record were perfect, but it took an hour to enter each one. You'd have patients dropping dead of a burst appendix sitting at the admissions desk. You face the same basic problem with things like airline ticket counter systems. Nobody would die, of course, but customers would find another airline if it took six hours to make their way through the ticket queue.
It makes sense to me, of course, because I'm used to it. But thinking about it in more depth, I guess it makes sense for a couple of reasons. First, ``tab'' on a typewriter sends the carriage to a different point in the line, where you can start typing something new. So using it to advance to the next field is a reasonable extension.
Also, it makes sense if you consider that ``enter'' is specifically for sending the entire screen to the system for processing. So ``enter'' to advance to the next field wouldn't work.
There is zero demand for XML web services on the right now
I think there's zero business model, too. Say FooCorp offers stock quotes on its web site. There are a few business models for that, although some of them might not be all that great. You can offer the service for free, sell advertising on the quotes page, and cross your fingers.
But there's basically no model for web services other than pay-for-play. FooCorp could offer their quotes through a SOAP or XML-RPC service or something, but there'd be no way to get secondary revenue from it. They'd have to just charge for the content directly, which hasn't been a very successful model on the web so far.
The fact that Google offers a web services-style API is cool, but it's unclear to me exactly how it helps their business.
I'm just speculating here, but I think web services will be much more popular in intranets than in commercial settings on the web, assuming somebody comes up with something that can be done better with web services than with a regular browser-based web app or a Java app or something.
It was nice of you to say so, at least, but for myself I don't really like it when people post affiliate links like this. This is too much like a barely-on-topic advertisement for my taste.
In case readers don't know, Amazon's affiliate program is basically a system of kickbacks. Person X signs up with the affiliate program and starts handing out special links to the Amazon site. If person Y clicks person X's special link and then buys something, person X gets a small amount of money from Amazon. They say up to 15% of what person Y spent, but I'm sure it's a lot less that than most of the time.
Long story short, people who post affiliate links to Amazon's site are really trying to maximize their gains from the affiliate program. I can't put my finger on it, but that just gives me a funny feeling for some reason.
I'm not flaming you or anything, so don't get mad. I'm just voicing my opinion. Slashdot soapbox and all that.
PHP is very nice, and very easy to use (especially compared to J2EE), but if you're doing some serious heavy enterprise/distributed application work, then it just doesn't cut it.
Agreed, 100%. We showed a web application demo at a recent trade show. The demo was written (by me) in about two weeks, using PHP and a custom-written interface to our proprietary database back-end. It worked fine... for the demo.
But we're implementing the real, non-demo application using J2EE technologies. There are a lot of things that you can do better-- more securely and more stably (is ``stably'' a word?)-- with Java and J2EE than you can with PHP, and there are a few things that you can't do with PHP at all. For example, one of the features of our web app would be that it opens a socket listener, then passes the IP and port of the listener (via a separate control socket) to the back-end. The back-end connects to the web app's listener socket and initiates a bulk data transfer. It works pretty much the same way FTP does, if you're familiar with the guts of that protocol.
As of last March, that simply was possible with PHP, as near as I could tell. You could open sockets to other computers, but you couldn't open a socket listener inside a PHP script instance. That's not cool, because using the web app to facilitate bulk data transfers between the back-end and the desktop is a major design feature for us.
And, of course, when you're working on a complex, distributed app with lots of components, the ``bondage-and-discipline'' features of Java come in handy. It's nice that non-exception-safe code won't even compile. Saves you time in test and debugging.
For example, take an HTML form. Let's say you had a few hundred choices for one of the textboxes on that form. It would be incredibly useful to be able to type in the few first letters of the text and press a button to search for all matches and display them in a selection box next to it.
But that's hard in any language on any platform, unless your platform happens to provide you with a widget that does that for you. (ViewKit does on SGI. Don't know about any of the others, 'cause I don't do GUI programming very often.)
I think you've got a valid point, but it doesn't justify your conclusion. In your example, you just need to redesign your UI slightly. A few hundred choices for a text box? Maybe there's a better way to present that to the user.
Sure, the HTML interface platform has severe limitations. But it's going too far to say that web applications will fail because of them. It's just that web applications are good for only a subset of what native desktop clients are good for. But within that subset, web apps are very useful.
My personal opinion on data entry, though, differs from the conventional wisdom. My girlfriend is a doctor so I've spent a little bit of time in hospitals. One time I watched a woman admit a patient. It took about five minutes, I guess. She was using an old-style forms-based data entry program on a text terminal, the kind where you fill out a whole screen of information and then send that screen to the computer downstairs for processing. She was incredibly fast, keying in a huge amount of data in just a few minutes. No messing around with clicky-clicky, no pulling down menus. Just type, tab, type, spacebar, type, tab, enter. Man, that was efficient.
Instead of trying to force a web app to behave like a Windows desktop app, maybe you should look at some older programs that use the same sort of screen-based paradigm that web pages use, and design your interface according to those well established conventions.
Where did you get that impression? I don't mean that rhetorically; I'm relatively new to Java development, having just started working with it about a year ago. What makes you say that Sun isn't driving Java? Just this winter they pushed out J2SE 1.4, and a beta of 1.4.1 is available now. Seems to me as though Sun is doing as much Java work now as ever, at least in my limited experience.
Okay, I admit I haven't read the article. (Whaddya expect? I just rolled out of bed a few minutes ago, and I'm only surfing Slashdot right now to avoid going to work.)
Nevertheless, I'm having a hard time understanding why this kind of hologram would be more useful than, say, a VR wall or room? I've seen some of SGI's demos of 3D visualization technology using Onyxes or Octanes, projectors, and stereo glasses. Granted, those images aren't truly volumetric, so you can't put your finger into them or anything... but the same is true of these holograms we're talking about. They only appear to be volumetric.
And a VR environment like that has the benefit of being in full color, with full interactive animation and whatnot. You can use the wireless mouse thingy to "grab" the model and rotate it on any axis, with frame rates from 120 all the way down to a few per second, depending on the complexity and the oomph behind your computer system. Sounds a lot cooler and more useful than a static hologram image to me.
I dunno. I guess I'm just not as dazzled by the word "hologram" as I was when I was seven.;-)
I hear people saying things like, "the system is built for corruption," but I don't hear anybody actually pointing out evidence of widespread corruption in the system. In other words, if all you have to say is, "this system sucks," I'm not really interested in listening.
Let's take your points one at a time.
how else does a country end up with a copyright that doesn't expire for 95 years?
Exactly how long should copyrights last? And why? Is it really appropriate, for example, for Mickey Mouse to revert to the public domain when it's still being actively used by its owner? To me it's entirely reasonable that intellectual property owned by a corporation should be protected by law for as long as that corporation exists, or some sensible upper bound. Copyright protection for IP owned by an individual lasts as long as that individual is alive, and then some. If I live to be 200 years old, my works would be protected for me by law for 200 years, plus a number of years after my death. It's reasonable to expect the same protection for IP owned by a corporation. Given that Paramount Pictures turned 90 this year, and that Coca-Cola is well over 100, a limit of 95 years for copyright protection for IP owned by a corporation seems to be, if anything, too short.
or patents on the most rediculous of ideas, or methods?
Since you didn't name anything specific, I can only guess as to what you're thinking of. In general, though, it's kinda silly for one person to call another person's idea obvious or trivial. As Douglas Adams said, "It is a rare mind indeed that can render the hitherto non-existent blindingly obvious. The cry 'I could have thought of that' is a very popular and misleading one, for the fact is that they didn't, and a very significant and revealing fact it is too."
Or laws such as the DMCA
I don't accept prima facie that the DMCA is a bad law. That's because I'm not an expert in law in general, or IP law in particular. So I have no prima facie opinion of the DMCA.
But if it is a bad law, it isn't the first. Bad laws make it onto the books all the time. That's part of how our system of government works, and that's why we have a judicial system. Laws are passed, challenged, and struck down every year in this country. The fact that a bad law has come into existence is not evidence of a flaw in the system. If it's unconstitutional, or badly written, or unenforceable, it'll be declared such by the courts when challenged.
or how about the RIAA wanting a piece of used cd sales?
Um. I don't see what that has to do with our system of government. If I were the RIAA, I'd want a piece of used CD sales, too, and so would you. What does that have to do with anything?
What I've been saying all along-- and continue to say now-- is this: none of these complaints are valid critiques of our system of government. If I agreed with every cry of injustice raised on Slashdot-- I don't-- I would still have no cause to find fault with our system of government. From my seat, the government of this country is working exactly as it should. We have all sorts of different parties-- individuals, groups of individuals, companies-- with conflicting agendas. Sometimes one or more of those parties is able to get their agenda implemented as public policy. On those occasions in which that public policy is in conflict with the law of the land, or is in some other way inherently flawed, the courts strike it down.
This is, in other words, exactly the way the Founding Fathers envisioned our system to be: dynamic, resilient, and strong.
Borrowing writing systems is common and does not mean that the languages are at all related.
Yup. My girlfriend is Vietnamese. Vietnamese, unlike all the other east Asian languages, uses the Roman alphabet, just like English. (Well, with the addition of a metric assload of diacriticals to designate tones and whatnot.) But English and Vietnamese are about as unrelated as two languages can be.
Similarly, the Cyrillic alphabet includes characters from the Greek alphabet, but that doesn't mean Russian is particularly closely related to Greek.
But of course the best example is Japanese and Chinese. A long time ago the Chinese ideograms made their way across the China Sea to Japan, where they became part of the Japanese language. In most cases-- or so I remember from my college Japanese courses-- the ideograms carry the same or similar meanings in both languages, but the Japanese have their own pronunciations for them, and of course the grammar and syntax of the languages are totally different. Even the basic semantics of the languages are different; the Chinese languages are tonal, where the pitch of a syllable carries meaning. Japanese doesn't convey meaning with pitch, even though they share the same basic set of ideograms.
My favorite part about OMWF was the attention to detail. Everybody who's seen it knows it was shot and aired in letterboxed widescreen. But not plain old HDTV-style widescreen. It was broadcast in the Cinemascope aspect ratio, just like the grand old musicals of the 40's. They even used the "scope," or 2.35:1, version of the 20th Century Fox title at the end, after the end credits and the Mutant Enemy card.
But the big question is this: was this episode shot with Cinemascope lenses? Ordinarily when you shoot a movie in the "flat" aspect ratio (1.85:1) you matte off the top and bottom of the 35 mm frame. But when you shoot Cinemascope, you use a special anamorphic lens that squeezes the picture horizontally, so you use the whole 35 mm frame. When you project the film through another anamorphic lens, the image gets stretched out into the proper aspect ratio.
So if OMWF was shot with Cinemascope lenses, then there's a beautiful 35 mm master out there on a shelf someplace just begging for an anamorphic transfer to DVD.
Of course, unless they accelerate the process, by the time we get Season 6 on DVD, we'll probably have access to a consumer HD DVD format. We can only hope.
Slashdot Mirror
Give us an incentive to buy your CDs and we'll buy it. Stop blatently rip us off!
Let me get this straight. You think that CDs are too expensive, therefore the RIAA is ripping you off. So you take music from the publishers (and, indirectly, from the RIAA) without paying for it, and this is okay.
Wait. I must have missed something.
The RIAA has tried (successfully) to paint P2P networks as festering cesspools of piracy and other sorts of illegal activity.
Log on to one of them and do a search for something random. Count the number of legitimate files you see-- meaning files that can be shared without breaking any contracts, rules, or laws-- and compare to the number of illegitimate files you see-- meaning files that shouldn't be shared. That ratio makes it pretty tough to call P2P networks anything other than festering cesspools of piracy.
Have you ever stopped to consider, through all of your knee-jerk reactions and unlikely political opinions, that the RIAA and the MPAA might actually have a point?
Companies like the RIAA and the MPAA are going to go out of business. Period. When people have the ability to make an infinite number of copies of your product, at virtually no cost, you can't make money anymore. It's as simple as that.
Then you'd better hang on tight to your favorite music and movies. Because there won't be much more of 'em. Music and movies aren't cheap to produce. Somebody has to put up the cash to get 'em made. Even though the artists themselves may not care about getting rich-- I'm sure some of them don't-- they're going to have to get funded somehow. If nobody believes they can make a profit by investing in a new movie, then nobody will do it, and the movie won't get made. No more 2001s. No more Citizen Kanes. No more.
Of course, I think your line of argument is full of shit, so I'm really not all that nervous.
In the eyes of publishers, libraries are nothing but open copyright violations. All the arguments being made about "piracy" apply directly to libraries.
Can you post one single source for this information? One out-of-context quote from an exec at Random House? Anything?
No personal offense intended, but your post sounded pretty made-up. I'm not accusing you of anything; I'd just like to know where you get these unusual ideas.
What business model follows naturally from relational databases?
You're kidding, right? Maintaining large sets of textual information is one of the oldest problems. Companies expend a metric assload of time and effort managing their information stores, from accounting to inventory to HR and on and on. Relational databases, with a few additional bits like form builders and report generators, let companies do that more efficiently. Instant ROI. That's a really clear business case.
What business model follows naturally from C++?
That's admittedly harder to define, but C++ is more abstract than web services technology is. Web services technology is, fundamentally, about exchanging information or commands between two applications over a TCP socket. Everything else is just the specifics of the standard(s). This naturally raises the question, ``Why do you want to exchange data or commands?'' To this question, there are lots of answers. But I can't readily think of a situation in which we need to exchange data or commands between two computers or two programs but can't yet because we don't have a technology for doing so. So the real question behind web services is this: ``What am I doing right now that can be significantly improved with web services technology, in some way that increases my efficiency, or that directly generates a profit for me?''
The direct route would be to use web services technology to offer new services for sale to customers. We've already beaten that dead horse; the bottom line is that companies aren't really rushing to offer for-pay services based on these new technologies.
The indirect route is what we're really talking about here. What can web services technology give me that will improve the way I do business and help me make more money? All of the examples you gave, ``integrate legacy systems, purchase syndicated content (like a Reuter's feed) in a standardized form, lower the cost of EDI and get more partners into the EDI game, etc,'' are already being done on large scales with other technologies. So one is left wondering how, exactly, web services technology will help anybody do those things better than they're currently doing them.
That's what I'm getting at. If an employee came to me and said, ``Let's deploy web services!'' I'd have to ask why. What potential gain can justify the expense and effort required to deploy that kind of technology in place of some other technology that we're already using now.
I guess I just don't see the problem that web services technology is trying to solve.
Damn IE! I was halfway through my post when somehow the focus shifted without my knowing it. I hit the ``delete'' key, and my browser went back one page. Damn!
People will pay for good products, no matter where or how they are made available.
While your statement sounds reasonable enough, I'm not sure we can jump to that conclusion. Can you name one non-informational content company that has broken even or made a profit selling their content through the Internet? By saying ``non-informational'' I mean to exclude companies like WestLaw; their business model is very clear and very solid. But I'm talking about content for which there isn't a fixed demand, like news or entertainment information for the mass market.
Companies like Conde Nast make a decent profit (as far as I know) publishing and selling magazines. Has there been any similar venture that has used the Internet as a delivery channel?
Ever considered combining PHP with C-based CGI?[...] Is that sort of solution unrealistic in the enterprise environment?
In my opinion, it is. For starters, writing CGI applications in C is painful and error-prone. Java servlets are faster and much easier to write cleanly. So there's no real reason to use C or C++-language CGI for anything, unless you're doing something tricky on the back end that just can't be done with Java.
On the other side of the coin, we've got PHP. PHP is easier to write and faster to develop than JSP, in my opinion, but harder to write in any sort of scalable way. For instance, JSP gives you tag libraries which can be used to abstract out some Java code without having to delve all the way into servlets. Very handy for presentation-layer automation. PHP doesn't give you that.
There are lots of little things, too. You can package up an entire web app into a couple of files, for instance, while deploying a PHP/CGI application requires the installation of a whole tree full of scripts and programs. A small thing, but it makes a difference in the long haul.
So I think the combination of PHP and CGI is better than PHP alone, but still losing in comparison to J2EE technolgies.
Any application can use the SOAP protocol to communicate with their server instead of proprietary binary, text, or XML formats; multi-tier architectures will increasingly use SOAP to communicate; etc.
What proprietary formats are you thinking of? CORBA is the opposite of proprietary, and it works very well. If you apply web services technologies to problems that are currently being solved with CORBA applications, you may find that the web services version is, at best, no better than the CORBA version.
I suppose one might argue that web services technologies are better suited to the high-latency environment of the internet, but I don't necessarily buy that. I run CORBA applications across the internet from home to office and vice-versa all the time, with no complaints.
Just like text, TCP/IP, HTTP, and XML, SOAP standardizes how computers talk to each other.
So does CORBA. So we have two competing implementations of the same basic idea. Question is, is SOAP better in any significant way? I haven't yet seen anything that says it is. In fact, the amount of effort required to marshall and de-marshall objects into XML seems prohibitive in a lot of situations. CORBA obviates that need through the standardized mappings of IDL constructs to native language types.
Second, the original poster argued that there is no *problem domain* for Web services.
Just for the record, no I didn't. (And neither did the guy above me. I'm not 100% sure who you're calling ``original'' here.)
The guy above me said that there's no demand for web services implementations or applications. I said there's no business model for using them, either. You pointed out that there are software-to-software applications for web services technologies that I hadn't thought of, which I concede, but I'm still not sure that means there's a B-to-B or B-to-C business model that requires them.
Note that I'm not talking about the same thing you're talking about. You're talking about problem spaces. What can we use web services technologies for? I'm talking about business cases. What can we do with web services that will either be profitable by itself, or enhance our profitability in some indirect way? These are two really different things.
Often technologies fail not because they themselves are inferior, or because nobody understands how they could use them. They often fail because nobody understands why they should use them.
Just clarifying my position a bit.
Salon did $1.1M selling subscriptions with over 30,000 sales. Sounds successful to me. Now, because they SPENT $75 million, doesn't mean that people "won't pay for content." (Web myth #47)
First of all, it's pretty silly of you to jump from my ``charging for content hasn't been a successful business model'' to ``people won't pay for content.'' These are two entirely different things.
But besides that, I'd say Salon's situation proves my point, not disproves it. Selling subscriptions hasn't helped them break even, so that model has, so far, not succeeded. That's the goal of a business model, after all: to either enable you to break even, or, preferably, make a profit. Salon hasn't done that. QED.
All of this is being written, by the way, by a guy who signed up for a Salon Premium subscription over a year ago.
(Uh-oh. OSQ coming on. Homer: ``Would you look at those morons... I paid my taxes over a year ago!'')
So, you see, the body of evidence available to us would suggest that the idea that the idea that people won't pay for content is a myth is, in fact, a myth. ("Huh?") Most businesses that have tried to turn pay-for-content into a profitable revenue model have failed to do so. So while it's not literally true that people won't pay for content under any circumstances, it's thus far been true that people won't pay in sufficient numbers or at sufficiently high rates to make selling content a profitable enterprise.
Then compare them both [PHP, JSP] with XSP - the choice is obviously for XSP.
:-(
Unless, if course, you want to be able to read your code.
I'm astounded by people who think XML is an acceptable language for writing code or documents. Just as writing in pure HTML is only for the gearest of the gearheads (myself included), writing pure XML, or XML with embedded logic like XSP, is painful in the extreme.
It's really getting to the point where XML and its derivatives are write-only formats, suitable for machine-to-machine communication only. Hell, even Ant pisses me off with its XML syntax for makefiles. I miss make.
So I just lean that way since it works so well for us so often. It is very easy to get into habits. It is good to hear other ways of doing something so that one does not get too entrenched in a single approach.
;-)
Now that's refreshing. All too often, GUI programmers were raised on the Mac Way, or (worse) the Windows Way, or (even worse) the Java Way, and they spend all of their time trying to shave the corners off of square pegs. What's worst of all, of course, is when your customer is entrenched in the Windows Way, and mandates the use of tabbed dialog boxes for data entry interfaces, then complains when the app is slow and hard to use.
Heh. You want a job?
You see before we had GUIs, and windows, next feild was always Enter. While tab seems to work in text/word processing, keypunch entry is another matter.
Ah, but I'm talking about a system even older than that. I'm talking about an IBM mainframe system with dumb terminals attached over serial lines. The mainframe sends you a screen, and you use the terminal to navigate through the fields and input data. Then you send the entire screen of data back to the mainframe for processing. It's not an interactive system. It's almost a batch processing system, except that you process each screen as you're done with it.
That's why the ``enter'' key couldn't be used for advance-to-next-field, because ``enter'' had to be used for process-this-screen-now.
That said, I'm sure you're right that ``tab'' is a bad thing if you spend all your time on the numeric keypad. But the kind of applications I'm thinking of were text-based, not number-based, so to those operators ``tab'' made more sense anyway.
I think you're kind of overstating your point to say, ``I have seen no benefit except confusion to the tab.'' It's more a case of one being better than the other in each situation.
There is really no comparison with browser based apps. Web services are for solving problems that cannot be solved with browser based apps because they do not involve human interaction. You cannot integrate CRM and accounting systems with a browser-based app.
Okay, that's a good point. I was only thinking of using web services protocols for connecting desktop applications to server applications. Connecting two server applications together with web services makes a lot more sense. Thanks for the clarification.
Data Entry Errors- large. The more freedom the user has- the more ways they will mess it up.
I suppose that's a valid point, but it falls to the application designers to put in all reasonable checks on input. You can't verify that a last name was spelled correctly, of course, but there's no way to guarantee that in the UI either. But for things like entering codes for medical billing (a huge, vast data processing job that most people aren't even aware of) you can put a good deal of sanity checking in the back-end system to minimize errors. You can't eliminate them, but you can cut 'em down quite a bit if your application is clever enough. For example, the system will initally reject a billing record that includes no surgical procedures, two nights in a room, and only five meals. The system knows that most non-surgical patients get fed three times a day, every day. If the patient had a surgical procedure, the system will accept the record, because it knows that surgical patients are always NPO for part of their stay. (Oh, NPO = ``nil per os,'' or ``nothing by mouth,'' meaning no food or drink.)
But like all things, it's a trade off. The hospital would have had a much bigger problem if every record were perfect, but it took an hour to enter each one. You'd have patients dropping dead of a burst appendix sitting at the admissions desk. You face the same basic problem with things like airline ticket counter systems. Nobody would die, of course, but customers would find another airline if it took six hours to make their way through the ticket queue.
I never understood TAB to advance a field.
It makes sense to me, of course, because I'm used to it. But thinking about it in more depth, I guess it makes sense for a couple of reasons. First, ``tab'' on a typewriter sends the carriage to a different point in the line, where you can start typing something new. So using it to advance to the next field is a reasonable extension.
Also, it makes sense if you consider that ``enter'' is specifically for sending the entire screen to the system for processing. So ``enter'' to advance to the next field wouldn't work.
There is zero demand for XML web services on the right now
I think there's zero business model, too. Say FooCorp offers stock quotes on its web site. There are a few business models for that, although some of them might not be all that great. You can offer the service for free, sell advertising on the quotes page, and cross your fingers.
But there's basically no model for web services other than pay-for-play. FooCorp could offer their quotes through a SOAP or XML-RPC service or something, but there'd be no way to get secondary revenue from it. They'd have to just charge for the content directly, which hasn't been a very successful model on the web so far.
The fact that Google offers a web services-style API is cool, but it's unclear to me exactly how it helps their business.
I'm just speculating here, but I think web services will be much more popular in intranets than in commercial settings on the web, assuming somebody comes up with something that can be done better with web services than with a regular browser-based web app or a Java app or something.
(Above is an affilate link)
It was nice of you to say so, at least, but for myself I don't really like it when people post affiliate links like this. This is too much like a barely-on-topic advertisement for my taste.
In case readers don't know, Amazon's affiliate program is basically a system of kickbacks. Person X signs up with the affiliate program and starts handing out special links to the Amazon site. If person Y clicks person X's special link and then buys something, person X gets a small amount of money from Amazon. They say up to 15% of what person Y spent, but I'm sure it's a lot less that than most of the time.
Long story short, people who post affiliate links to Amazon's site are really trying to maximize their gains from the affiliate program. I can't put my finger on it, but that just gives me a funny feeling for some reason.
I'm not flaming you or anything, so don't get mad. I'm just voicing my opinion. Slashdot soapbox and all that.
PHP is very nice, and very easy to use (especially compared to J2EE), but if you're doing some serious heavy enterprise/distributed application work, then it just doesn't cut it.
Agreed, 100%. We showed a web application demo at a recent trade show. The demo was written (by me) in about two weeks, using PHP and a custom-written interface to our proprietary database back-end. It worked fine... for the demo.
But we're implementing the real, non-demo application using J2EE technologies. There are a lot of things that you can do better-- more securely and more stably (is ``stably'' a word?)-- with Java and J2EE than you can with PHP, and there are a few things that you can't do with PHP at all. For example, one of the features of our web app would be that it opens a socket listener, then passes the IP and port of the listener (via a separate control socket) to the back-end. The back-end connects to the web app's listener socket and initiates a bulk data transfer. It works pretty much the same way FTP does, if you're familiar with the guts of that protocol.
As of last March, that simply was possible with PHP, as near as I could tell. You could open sockets to other computers, but you couldn't open a socket listener inside a PHP script instance. That's not cool, because using the web app to facilitate bulk data transfers between the back-end and the desktop is a major design feature for us.
And, of course, when you're working on a complex, distributed app with lots of components, the ``bondage-and-discipline'' features of Java come in handy. It's nice that non-exception-safe code won't even compile. Saves you time in test and debugging.
For example, take an HTML form. Let's say you had a few hundred choices for one of the textboxes on that form. It would be incredibly useful to be able to type in the few first letters of the text and press a button to search for all matches and display them in a selection box next to it.
But that's hard in any language on any platform, unless your platform happens to provide you with a widget that does that for you. (ViewKit does on SGI. Don't know about any of the others, 'cause I don't do GUI programming very often.)
I think you've got a valid point, but it doesn't justify your conclusion. In your example, you just need to redesign your UI slightly. A few hundred choices for a text box? Maybe there's a better way to present that to the user.
Sure, the HTML interface platform has severe limitations. But it's going too far to say that web applications will fail because of them. It's just that web applications are good for only a subset of what native desktop clients are good for. But within that subset, web apps are very useful.
My personal opinion on data entry, though, differs from the conventional wisdom. My girlfriend is a doctor so I've spent a little bit of time in hospitals. One time I watched a woman admit a patient. It took about five minutes, I guess. She was using an old-style forms-based data entry program on a text terminal, the kind where you fill out a whole screen of information and then send that screen to the computer downstairs for processing. She was incredibly fast, keying in a huge amount of data in just a few minutes. No messing around with clicky-clicky, no pulling down menus. Just type, tab, type, spacebar, type, tab, enter. Man, that was efficient.
Instead of trying to force a web app to behave like a Windows desktop app, maybe you should look at some older programs that use the same sort of screen-based paradigm that web pages use, and design your interface according to those well established conventions.
Sun isn't driving it as hard as it used to
Where did you get that impression? I don't mean that rhetorically; I'm relatively new to Java development, having just started working with it about a year ago. What makes you say that Sun isn't driving Java? Just this winter they pushed out J2SE 1.4, and a beta of 1.4.1 is available now. Seems to me as though Sun is doing as much Java work now as ever, at least in my limited experience.
Okay, I admit I haven't read the article. (Whaddya expect? I just rolled out of bed a few minutes ago, and I'm only surfing Slashdot right now to avoid going to work.)
;-)
Nevertheless, I'm having a hard time understanding why this kind of hologram would be more useful than, say, a VR wall or room? I've seen some of SGI's demos of 3D visualization technology using Onyxes or Octanes, projectors, and stereo glasses. Granted, those images aren't truly volumetric, so you can't put your finger into them or anything... but the same is true of these holograms we're talking about. They only appear to be volumetric.
And a VR environment like that has the benefit of being in full color, with full interactive animation and whatnot. You can use the wireless mouse thingy to "grab" the model and rotate it on any axis, with frame rates from 120 all the way down to a few per second, depending on the complexity and the oomph behind your computer system. Sounds a lot cooler and more useful than a static hologram image to me.
I dunno. I guess I'm just not as dazzled by the word "hologram" as I was when I was seven.
I hear people saying things like, "the system is built for corruption," but I don't hear anybody actually pointing out evidence of widespread corruption in the system. In other words, if all you have to say is, "this system sucks," I'm not really interested in listening.
Let's take your points one at a time.
how else does a country end up with a copyright that doesn't expire for 95 years?
Exactly how long should copyrights last? And why? Is it really appropriate, for example, for Mickey Mouse to revert to the public domain when it's still being actively used by its owner? To me it's entirely reasonable that intellectual property owned by a corporation should be protected by law for as long as that corporation exists, or some sensible upper bound. Copyright protection for IP owned by an individual lasts as long as that individual is alive, and then some. If I live to be 200 years old, my works would be protected for me by law for 200 years, plus a number of years after my death. It's reasonable to expect the same protection for IP owned by a corporation. Given that Paramount Pictures turned 90 this year, and that Coca-Cola is well over 100, a limit of 95 years for copyright protection for IP owned by a corporation seems to be, if anything, too short.
or patents on the most rediculous of ideas, or methods?
Since you didn't name anything specific, I can only guess as to what you're thinking of. In general, though, it's kinda silly for one person to call another person's idea obvious or trivial. As Douglas Adams said, "It is a rare mind indeed that can render the hitherto non-existent blindingly obvious. The cry 'I could have thought of that' is a very popular and misleading one, for the fact is that they didn't, and a very significant and revealing fact it is too."
Or laws such as the DMCA
I don't accept prima facie that the DMCA is a bad law. That's because I'm not an expert in law in general, or IP law in particular. So I have no prima facie opinion of the DMCA.
But if it is a bad law, it isn't the first. Bad laws make it onto the books all the time. That's part of how our system of government works, and that's why we have a judicial system. Laws are passed, challenged, and struck down every year in this country. The fact that a bad law has come into existence is not evidence of a flaw in the system. If it's unconstitutional, or badly written, or unenforceable, it'll be declared such by the courts when challenged.
or how about the RIAA wanting a piece of used cd sales?
Um. I don't see what that has to do with our system of government. If I were the RIAA, I'd want a piece of used CD sales, too, and so would you. What does that have to do with anything?
What I've been saying all along-- and continue to say now-- is this: none of these complaints are valid critiques of our system of government. If I agreed with every cry of injustice raised on Slashdot-- I don't-- I would still have no cause to find fault with our system of government. From my seat, the government of this country is working exactly as it should. We have all sorts of different parties-- individuals, groups of individuals, companies-- with conflicting agendas. Sometimes one or more of those parties is able to get their agenda implemented as public policy. On those occasions in which that public policy is in conflict with the law of the land, or is in some other way inherently flawed, the courts strike it down.
This is, in other words, exactly the way the Founding Fathers envisioned our system to be: dynamic, resilient, and strong.
Your complaints are unfounded.
Borrowing writing systems is common and does not mean that the languages are at all related.
Yup. My girlfriend is Vietnamese. Vietnamese, unlike all the other east Asian languages, uses the Roman alphabet, just like English. (Well, with the addition of a metric assload of diacriticals to designate tones and whatnot.) But English and Vietnamese are about as unrelated as two languages can be.
Similarly, the Cyrillic alphabet includes characters from the Greek alphabet, but that doesn't mean Russian is particularly closely related to Greek.
But of course the best example is Japanese and Chinese. A long time ago the Chinese ideograms made their way across the China Sea to Japan, where they became part of the Japanese language. In most cases-- or so I remember from my college Japanese courses-- the ideograms carry the same or similar meanings in both languages, but the Japanese have their own pronunciations for them, and of course the grammar and syntax of the languages are totally different. Even the basic semantics of the languages are different; the Chinese languages are tonal, where the pitch of a syllable carries meaning. Japanese doesn't convey meaning with pitch, even though they share the same basic set of ideograms.
Languages are cool.
My favorite part about OMWF was the attention to detail. Everybody who's seen it knows it was shot and aired in letterboxed widescreen. But not plain old HDTV-style widescreen. It was broadcast in the Cinemascope aspect ratio, just like the grand old musicals of the 40's. They even used the "scope," or 2.35:1, version of the 20th Century Fox title at the end, after the end credits and the Mutant Enemy card.
But the big question is this: was this episode shot with Cinemascope lenses? Ordinarily when you shoot a movie in the "flat" aspect ratio (1.85:1) you matte off the top and bottom of the 35 mm frame. But when you shoot Cinemascope, you use a special anamorphic lens that squeezes the picture horizontally, so you use the whole 35 mm frame. When you project the film through another anamorphic lens, the image gets stretched out into the proper aspect ratio.
So if OMWF was shot with Cinemascope lenses, then there's a beautiful 35 mm master out there on a shelf someplace just begging for an anamorphic transfer to DVD.
Of course, unless they accelerate the process, by the time we get Season 6 on DVD, we'll probably have access to a consumer HD DVD format. We can only hope.
(Though we did get the whole OMWF on video.) (yeah, I know, I don't own a PVR. bad geek. bad. bad geek.)
Heh. I told my TiVo to save OMWF "until I delete." It's been on there, at the bottom of my "now playing" list, since last November.