The MSFT deployment of R/3 was actually quite interesting back when it was the "big news" of 1996. I actually got email from a recruiter at MSFT when they were looking for people. (I was a little stunned at the time by that...)
At any rate, the "platform politicking" was a big deal. That was the same year when MSFT was heavily marketing that Windows NT was an excellent platform for running R/3. At that point, on Oracle, because it wasn't 'til about '97 or '98 that Microsoft's version of Sybase became supported.
The richly entertaining part was that Microsoft wasn't "eating their own dogfood," even though they were promoting it, heavily. It would have been a marketing disaster had they run their system on Unix + Oracle, so they sidestepped it by initially going with IBM AS/400 + DB/2. And then invested heavily in the systems integration projects to get R/3 to run on Windows NT + MS SQL Server.
If you search the web, you'll have a HARD time finding any evidence of the AS/400 installation; that's the sort of information that Microsoft's "Winston Smiths" would be expected to work overtime to expunge from public record...
For SAPDB to be acceptable for inclusion in Linux distributions requires that people involved with that be able to compile it.
I use PostgreSQL in contexts where we don't have root access on colocated hardware, which mandates that we have to be able to compile it (and various other software) to run as we see fit. That is the sort of thing I need , your opinions of who's a nutter notwithstanding.
And the issue isn't simply that SAP-DB is tough to compile; it is also troublesome that the code base is pretty "reader-hostile," to the point that the only people prepared to invest the time to fight through it are those that get paid by SAP AG for it. You don't care about that? Well, it's a good thing that some of us do...
No, Microsoft uses SAP's Enterprise Resource Planning software for things like financial accounting. Accounts Receivable, Accounts Payable, General Ledger, Sales Management, that sort of thing. (In SAP nomenclature, FI/CO, SD, possibly MM,...)
The main software that SAP sells is the set of applications that use a database (in Microsoft's case, a code fork of Sybase SQL Server). The DBMS is the smallest part of the code that is running...
The discussion is not about the "huge, complex application," R/3, it is about the database.
And in the context of R/3, the database is essentially an embedded component, a tiny part of the overall system, and one that isn't used with immense sophistication. Most big R/3 installs use Oracle, but, for the most part, not in a terribly sophisticated way. There is little if any use of "advanced stuff" like foreign keys, triggers, or stored procedures; the DBMS is used as a "data store," and isn't expected to be terribly smart.
There lies an interesting connection; that description historically describes MySQL fairly well, as a relatively unsophisticated data store. Make MySQL more robust and it might well make a nice "cheap" data store for R/3 . (Mind you, commercial licenses for MySQL cost hundreds of dollars more, per CPU, than, say, PostgreSQL...)
But the "resume connection" certainly doesn't appear to be the point...
I think this hits the nail on the head. There are benefits to both sides in the deal:
MySQL contributes "name recognition" and popularity;
SAP-DB contributes a whole lot of functionality
Correspondingly, they also may have some ability to cover one anothers' weaknesses:
Compiling SAP-DB is, as you say, nearly impossible.
The code base is exceedingly obscure, and having the MySQL folk do some work on it may relieve that problem somewhat.
MySQL has some severe functionality deficiencies from the perspectives of anyone accustomed to DBMSes with mature transaction support, relational capabilities, and support for SQL features that go beyond minimal "entry level" stuff.
SAP-DB has fairly mature answers for all those deficiencies.
Of course, the code bases are presently entirely separate, so that ripping things down to build them back up is likely to be a multi-year project. Compare with Mozilla; when its source was "opened," they had to rip out all sorts of code from Rogue Wave, The Open Group, and others, and the results weren't useful until a LOT of work got done.
In that interim, "mindshare competitors" such as PostgreSQL and Firebird ("the database, not the web browser":-)) aren't likely to stand still, so it seems likely to me that a major result will be for them to get a lot more popular.
That seems a separate problem that would point to Tucows as the "nexus" of the problem.
If you're running a recent whois, it should hit whois.publicinterestregistry.net looking for slashdot.org. That whois server will "fess up" to part of the info, but fundamentally forward you to whois.opensrs.net , which is where the authoritative whois info resides.
The question is, what was the "broken" entry? If it said "NONAUTHORITATIVE," which I'd expect, then that indicates that you got valid (albeit intentionally incomplete) data out of the PIR whois, but then couldn't go to OpenSRS to get the real data.
That either leads to:
There being a problem at Tucows (who run OpenSRS), where they weren't responding to your requests, or
There being a connectivity problem somewhere between your location and whois.opensrs.net .
The latter strikes me as being more likely; apparently there was a bad outage around Boston due to a cable being cut, and that might have temporarily broken all sorts of routing.
Note that none of these scenarios actually point to there being a problem at PIR. From what I have seen, so far, I haven't seen any evidence suggestive of there being problems there. (Aside from wild stories in The Registry, of course!)
I never got paged about it, and I certainly would have had things gone down.
It seems more plausible that the problem stems from an out-of-date version of whois.
Version 4.6.2 (released in March) introduced a "patch" redirecting.ORG requests to whois.publicinterestregistry.net ; I'd suggest you check version numbers. Chances are that you're running something reasonably new.
It's plausible that VGRS might have been forwarding requests over to PIR, and shut that capability off this weekend, thereby causing "some inconvenience" to those using out-of-date whois clients.
Taking a look at the posts that led to the Register article, it appears that they headed down a garden path rather like this:
"We're having a problem; perhaps it's one of several things" to
"Now, we're publishing an article, with the wildest conspiracy theory we can imagine!", namely
The registry for all.org domains appears to have collapsed - meaning that all the details of who owns any.org domain are unobtainable.
Alternatively, perhaps CRSNIC, the putative point of failure, is having a problem?
He didn't make his statements in the United States
Why on earth does it make sense for statements made in a foreign country by an alien, to whom the US Constitution and Bill of Rights are not reasonably expected to apply?
The FBI certainly shouldn't be coming to the "hackathon", since it was to take place in Calgary, which, the last I heard, wasn't within FBI jurisdiction.
It doesn't make sense for the FBI to be able to arrest him; they aren't even in the same country. Again, Calgary isn't within FBI jurisdiction.
It's not as if this sort of thing is new. The makers of StarOffice showed similar disrespect when they called their presentation software Impress, conflicting with Chris Cox's presentation software package of the same name. Nobody spammed Slashdot over this; there were no boycotts of StarOffice over it. And the situation remains, to this day. Why does the FirebirdSQL group think they should expect better treatment now?
Unfortunately, that's a case of "two wrongs not making a right."
In the long run, it would reflect really badly on you, as you'd be demonstrating that you're a liar, prepared to act in bad faith, and, overall, untrustworthy for any important purpose.
I dislike MSFT as much as most; for someone to go in as a sort of "virtual terrorist" doesn't make them right...
We're talking about Naive Bayesian Filtering, where the assumption is made that we can assume the use of Bayes' formula even though we know it's not quite independent.
What you're missing is that the real formula doesn't just involve two words; it involves all of the words in the message.
The usual formula is
Rf, and you'll notice that it involves multiplying the occurrances of words in the message with the logarithm of their frequencies in each folder.
The word "sexy" may usually be enough to consign messages to the Spam/Websex folder, but if there are some occurances of the term "sexy window manager" in a discussion of some window managers, the fact that the names Enlightenment, WindowMaker, stupid , memory-hungry and themes occur rather a lot in X/WM and never in the Spam folders means the relevance total will most likely favor the right folder.
There may be a bit of a "fight" between the words, but if all the messages containing the string my_wife@frobozz.org go in the Honey folder, and occasionally contain phrases like That dress was so sexy or the likes, that will change the Ff(w) value for f = Honey , and the message will be appropriately routed, perhaps into the subfolder Honey/Rendezvous where you put the weekly messages of that sort from your wife.
Of course, there's then the non-technical problem, namely locating a wife that would actually send that message.
"Since oral sex is topologically equivalent to anal sex, converting one to the other is simply a matter of finding the right conformal map. Currently I only have solutions for a spherical girlfriend." -- Robert Bowler
No, the approach does not make any assumptions about words being constructed in English.
The "foreign language" Spam that I get gets nicely refiled by Ifile into my Spam/Foreign folder.
That folder has a corpus of messages assortedly written in Han, French, Kanji, Korean, Finnish, French, Spanish, and Russian, and Ifile nicely recognizes that words in those languages provide evidence that messages seem most relevant to go into that folder.
Ultimately, it all involves human classification:
Initially, the corpus must be "primed" with an initial set of messages that I classify into the various categories I want to distinguish between.
Some messages are processed by Ifile into an appropriate mail folder.
I go through them, and read them, perhaps just browsing titles when I see that spam seems appropriately filed.
By leaving the messages in the folder, indicate that they were correctly filed, and should become part of the corpus.
Ifile drops some messages in the wrong folder.
That then involves human intervention as I move the messages to where they should have been.
Note that IFile is useful for filing good messages, not merely at throwing away spam.
Indeed, the more that you use Bayesian filtering for, the more folders with distinctive kinds of message that you have, the better it gets at discriminating where messages should go. I don't have one "Spam" folder; I've got about 8 for different sorts of spam. I don't have one 'inbox' for all my "good" mail; the mail gets thrown into a veritable huge chasm of mail folders. The more there are, the better.
In my "corpus," consisting of many years of
MH mail (quite a bit more than Graham's, I think), processed using
Ifile, my stats for "sexy" pretty nicely pin down messages to either the Spam/Phonesex or Spam/Snakeoil folders. The word sex is rather less useful, as the word comes up in rather more common contexts than spam.
But this isn't enough, by itself, to classify a message. Messages do not solely consist of one or two words; they consist of many. And collecting the statistics together requires calculating a "relevance factor," based on all the words.
The one used for Naive Bayesian Inference is as follows:
Rf calculation , and you'll notice it involves doing a logarithm-based weighting.
The formula doesn't care what words are used, or that you think one folder contains "spam" and that another contains "gold."
In my corpus, the word sex is used in 65 different mail folders, mostly probably pretty "innocently."
Drawing conclusions based on one or two words is, unfortunately, pretty incomplete. It might well be that the one use of "sexy" in a particular message doesn't force it into the Spam/Phonesex folder because it makes even more extensive mention of Enlightenment and WindowMaker and GTK Themes and winds up being very strongly tied to the X/WindowManager folder because there are several other words not related to sexual activity that make it (correctly) appear relevant to a discussion of window managers.
Graham is drawing an analogy based on two words (words likely to grip adolescent attention!); reality involves adding everything up, and those two words certainly don't tell the whole story of the whole corpus.
I did a lot of tuning on Ifile, which I've been using for this purpose for about five years now.
Consider:
It's doing FULL TEXT word search. The HTML is looked at.
Are they really going to generate different "innocuous" messages?
If they are REPEATED innocuous messages that match against PAST "innocuous" messages that I decided were spam, that is going to pick this up.
Fool me once, shame on you.
Then your message goes into the corpus as "spam."
And messages that are written as multipart/alternative with statistically similar "innocuous" messages will be matched as spam.
The only "Wealth Of Evidence" that you can provide in an email to me that you aren't sending spam is for you to send me messages that have similar statistical parameters to those messages that I did not consider to be spam.
You don't know the parameters. The parameters essentially involve the subjects I discuss with my family, or with friends, or with business associates, or with technical associates.
How can you possibly construct, as a "spam-meister," messages that resemble those without being someone that I regularly communicate with?
There are several problems with where SAP-DB is now that injure its, oh, call it "usability."
The name is far newer than the "grand old names" of MySQL and PostgreSQL.
Marketing is of some importance, and the "other guys" have more of it. There are no books on bookstore shelves on SAP-DB. Few web sites "Powered by SAP-DB."
The code base is really frightening to work with.
It's quite a different world, with very different build tools, code documented in German, and the likes. It is not something that is easy to hack on.
The install is daunting.
There aren't colloquial packages available ubiquitously for Linux and BSD systems.
You can get a tarball, you can get some RPMs that work in some places, but it's not nearly as available as MySQL and PostgreSQL.
There aren't the pile of third party packages, ready to rpm -i or apt-get install into place.
Much of the popularity of MySQL stems from there being integrated ISP tools like CPanel that include a DB manager module specifically for MySQL. Similarly, the joint popularity of MySQL and PHP stems from the groups of developers working together closely to ensure that there is good native support for MySQL in PHP.
In contrast, modules for integrating SAP-DB with Perl, Python, PHP, and the like require some degree of effort in "hacking it into place." It's not as simple as "apt-get install python-sapdb sapdb-dbi php-sapdb".
And TOra doesn't include SAP-DB support.
None of these are particularly "technical" matters indicating things that can't work.
It's not a question of "SAP-DB not being an ACID DBMS" (as some idiot claimed in another thread).
It's really largely a question of systemms integration, with a certain amount of "needs more marketing."
It means that they don't have to render pretty HTML for you; they potentially pass you a smaller amount of data, which may lead to their having to do less work.
And as for "not having to visit their site," remember that they're not doing huge amounts of banner ads.
It's not totally evident that this "destroys" any of their business.
They still get to collect statistics on what queries come from where on what, which doesn't change terribly much whether they're receiving queries as HTML FORMs or XML SCHEMAs, and there's only a little reason for them to care about folks receiving back HTML versus XML
4/01 is coming...
on
To The Pain
·
· Score: 3, Interesting
And it would be entirely appropriate to propose an RFC that, amongst other things, specified:
WSDL schemas so that you could do this using SOAP;
Microsoft IDL, so that you could do this using COM;
PDF is a specification on which Apple based their own scheme, Quartz.
There is no such thing, in formal terms, as "Display PDF." Neither Apple nor Adobe use that name. Apple calls their thing (which, as near as can be told, has NO Adobe encumbrances) Quartz. Adobe has a document format that they call PDF, but nothing that they call "Display PDF."
If you use Ghostscript (from one of the runners-up!), then you're using Postscript, and haven't forcibly licensed anything from Adobe.
On the other hand, if you read a PDF document using acroread, you do have to have a valid license from Adobe
What happened with DPS was that Adobe was not prepared to continue licensing it to Apple under terms they were prepared to agree on. The natural result was that Apple went away and implemented their own thing, namely a "Display PDF" renderer, called Quartz.
The notion that this has much of anything to do with the formats is just silly...
For those that think GNOME and KDE are too big and bloated, this is moving towards being usable for some applications.
Keeping relevance, if L. Peter Deutsch didn't win, the somewhat-inadequacy of DGS work that the FSF contracted for might very well be part of the reason...
Slashdot Mirror
At any rate, the "platform politicking" was a big deal. That was the same year when MSFT was heavily marketing that Windows NT was an excellent platform for running R/3. At that point, on Oracle, because it wasn't 'til about '97 or '98 that Microsoft's version of Sybase became supported.
The richly entertaining part was that Microsoft wasn't "eating their own dogfood," even though they were promoting it, heavily. It would have been a marketing disaster had they run their system on Unix + Oracle, so they sidestepped it by initially going with IBM AS/400 + DB/2. And then invested heavily in the systems integration projects to get R/3 to run on Windows NT + MS SQL Server.
If you search the web, you'll have a HARD time finding any evidence of the AS/400 installation; that's the sort of information that Microsoft's "Winston Smiths" would be expected to work overtime to expunge from public record...
I use PostgreSQL in contexts where we don't have root access on colocated hardware, which mandates that we have to be able to compile it (and various other software) to run as we see fit. That is the sort of thing I need , your opinions of who's a nutter notwithstanding.
And the issue isn't simply that SAP-DB is tough to compile; it is also troublesome that the code base is pretty "reader-hostile," to the point that the only people prepared to invest the time to fight through it are those that get paid by SAP AG for it. You don't care about that? Well, it's a good thing that some of us do...
The main software that SAP sells is the set of applications that use a database (in Microsoft's case, a code fork of Sybase SQL Server). The DBMS is the smallest part of the code that is running...
But these issues aren't relevant to this thread.
The discussion is not about the "huge, complex application," R/3, it is about the database.
And in the context of R/3, the database is essentially an embedded component, a tiny part of the overall system, and one that isn't used with immense sophistication. Most big R/3 installs use Oracle, but, for the most part, not in a terribly sophisticated way. There is little if any use of "advanced stuff" like foreign keys, triggers, or stored procedures; the DBMS is used as a "data store," and isn't expected to be terribly smart.
There lies an interesting connection; that description historically describes MySQL fairly well, as a relatively unsophisticated data store. Make MySQL more robust and it might well make a nice "cheap" data store for R/3 . (Mind you, commercial licenses for MySQL cost hundreds of dollars more, per CPU, than, say, PostgreSQL...)
But the "resume connection" certainly doesn't appear to be the point...
- MySQL contributes "name recognition" and popularity;
- SAP-DB contributes a whole lot of functionality
Correspondingly, they also may have some ability to cover one anothers' weaknesses:- Compiling SAP-DB is, as you say, nearly impossible.
- MySQL has some severe functionality deficiencies from the perspectives of anyone accustomed to DBMSes with mature transaction support, relational capabilities, and support for SQL features that go beyond minimal "entry level" stuff.
Of course, the code bases are presently entirely separate, so that ripping things down to build them back up is likely to be a multi-year project. Compare with Mozilla; when its source was "opened," they had to rip out all sorts of code from Rogue Wave, The Open Group, and others, and the results weren't useful until a LOT of work got done.The code base is exceedingly obscure, and having the MySQL folk do some work on it may relieve that problem somewhat.
SAP-DB has fairly mature answers for all those deficiencies.
In that interim, "mindshare competitors" such as PostgreSQL and Firebird ("the database, not the web browser" :-)) aren't likely to stand still, so it seems likely to me that a major result will be for them to get a lot more popular.
That seems a separate problem that would point to Tucows as the "nexus" of the problem.
If you're running a recent whois, it should hit whois.publicinterestregistry.net looking for slashdot.org. That whois server will "fess up" to part of the info, but fundamentally forward you to whois.opensrs.net , which is where the authoritative whois info resides.
The question is, what was the "broken" entry? If it said "NONAUTHORITATIVE," which I'd expect, then that indicates that you got valid (albeit intentionally incomplete) data out of the PIR whois, but then couldn't go to OpenSRS to get the real data.
That either leads to:
The latter strikes me as being more likely; apparently there was a bad outage around Boston due to a cable being cut, and that might have temporarily broken all sorts of routing.
Note that none of these scenarios actually point to there being a problem at PIR. From what I have seen, so far, I haven't seen any evidence suggestive of there being problems there. (Aside from wild stories in The Registry, of course!)
I never got paged about it, and I certainly would have had things gone down.
It seems more plausible that the problem stems from an out-of-date version of whois.
Version 4.6.2 (released in March) introduced a "patch" redirecting .ORG requests to whois.publicinterestregistry.net ; I'd suggest you check version numbers. Chances are that you're running something reasonably new.
It's plausible that VGRS might have been forwarding requests over to PIR, and shut that capability off this weekend, thereby causing "some inconvenience" to those using out-of-date whois clients.
Taking a look at the posts that led to the Register article, it appears that they headed down a garden path rather like this:
Alternatively, perhaps CRSNIC, the putative point of failure, is having a problem?
Why on earth does it make sense for statements made in a foreign country by an alien, to whom the US Constitution and Bill of Rights are not reasonably expected to apply?
The FBI certainly shouldn't be coming to the "hackathon", since it was to take place in Calgary, which, the last I heard, wasn't within FBI jurisdiction.
It doesn't make sense for the FBI to be able to arrest him; they aren't even in the same country. Again, Calgary isn't within FBI jurisdiction.
It's not as if this sort of thing is new.
The makers of StarOffice showed similar disrespect when they called their presentation software Impress, conflicting with Chris Cox's presentation software package of the same name.
Nobody spammed Slashdot over this; there were no boycotts of StarOffice over it. And the situation remains, to this day.
Why does the FirebirdSQL group think they should expect better treatment now?
Unfortunately, that's a case of "two wrongs not making a right." In the long run, it would reflect really badly on you, as you'd be demonstrating that you're a liar, prepared to act in bad faith, and, overall, untrustworthy for any important purpose. I dislike MSFT as much as most; for someone to go in as a sort of "virtual terrorist" doesn't make them right...
We're talking about Naive Bayesian Filtering, where the assumption is made that we can assume the use of Bayes' formula even though we know it's not quite independent.
What you're missing is that the real formula doesn't just involve two words; it involves all of the words in the message.
The usual formula is Rf, and you'll notice that it involves multiplying the occurrances of words in the message with the logarithm of their frequencies in each folder.
The word "sexy" may usually be enough to consign messages to the Spam/Websex folder, but if there are some occurances of the term "sexy window manager" in a discussion of some window managers, the fact that the names Enlightenment, WindowMaker, stupid , memory-hungry and themes occur rather a lot in X/WM and never in the Spam folders means the relevance total will most likely favor the right folder.
As Ifile source code is available that dates back as far as about 1996.
The typical formula is
Relevance - Rf
There may be a bit of a "fight" between the words, but if all the messages containing the string my_wife@frobozz.org go in the Honey folder, and occasionally contain phrases like That dress was so sexy or the likes, that will change the Ff(w) value for f = Honey , and the message will be appropriately routed, perhaps into the subfolder Honey/Rendezvous where you put the weekly messages of that sort from your wife.
Of course, there's then the non-technical problem, namely locating a wife that would actually send that message.
The "foreign language" Spam that I get gets nicely refiled by Ifile into my Spam/Foreign folder.
That folder has a corpus of messages assortedly written in Han, French, Kanji, Korean, Finnish, French, Spanish, and Russian, and Ifile nicely recognizes that words in those languages provide evidence that messages seem most relevant to go into that folder.
Ultimately, it all involves human classification:
I go through them, and read them, perhaps just browsing titles when I see that spam seems appropriately filed.
By leaving the messages in the folder, indicate that they were correctly filed, and should become part of the corpus.
That then involves human intervention as I move the messages to where they should have been.
Note that IFile is useful for filing good messages, not merely at throwing away spam.
Indeed, the more that you use Bayesian filtering for, the more folders with distinctive kinds of message that you have, the better it gets at discriminating where messages should go. I don't have one "Spam" folder; I've got about 8 for different sorts of spam. I don't have one 'inbox' for all my "good" mail; the mail gets thrown into a veritable huge chasm of mail folders. The more there are, the better.
But this isn't enough, by itself, to classify a message. Messages do not solely consist of one or two words; they consist of many. And collecting the statistics together requires calculating a "relevance factor," based on all the words.
The one used for Naive Bayesian Inference is as follows: Rf calculation , and you'll notice it involves doing a logarithm-based weighting.
The formula doesn't care what words are used, or that you think one folder contains "spam" and that another contains "gold."
In my corpus, the word sex is used in 65 different mail folders, mostly probably pretty "innocently."
Drawing conclusions based on one or two words is, unfortunately, pretty incomplete. It might well be that the one use of "sexy" in a particular message doesn't force it into the Spam/Phonesex folder because it makes even more extensive mention of Enlightenment and WindowMaker and GTK Themes and winds up being very strongly tied to the X/WindowManager folder because there are several other words not related to sexual activity that make it (correctly) appear relevant to a discussion of window managers.
Graham is drawing an analogy based on two words (words likely to grip adolescent attention!); reality involves adding everything up, and those two words certainly don't tell the whole story of the whole corpus.
Consider:
If they are REPEATED innocuous messages that match against PAST "innocuous" messages that I decided were spam, that is going to pick this up.
Then your message goes into the corpus as "spam."
And messages that are written as multipart/alternative with statistically similar "innocuous" messages will be matched as spam.
You don't know the parameters. The parameters essentially involve the subjects I discuss with my family, or with friends, or with business associates, or with technical associates.
How can you possibly construct, as a "spam-meister," messages that resemble those without being someone that I regularly communicate with?
No, this "defeat" represents nothing of the sort.
Marketing is of some importance, and the "other guys" have more of it. There are no books on bookstore shelves on SAP-DB. Few web sites "Powered by SAP-DB."
It's quite a different world, with very different build tools, code documented in German, and the likes. It is not something that is easy to hack on.
You can get a tarball, you can get some RPMs that work in some places, but it's not nearly as available as MySQL and PostgreSQL.
Much of the popularity of MySQL stems from there being integrated ISP tools like CPanel that include a DB manager module specifically for MySQL. Similarly, the joint popularity of MySQL and PHP stems from the groups of developers working together closely to ensure that there is good native support for MySQL in PHP.
In contrast, modules for integrating SAP-DB with Perl, Python, PHP, and the like require some degree of effort in "hacking it into place." It's not as simple as "apt-get install python-sapdb sapdb-dbi php-sapdb".
And TOra doesn't include SAP-DB support.
None of these are particularly "technical" matters indicating things that can't work.
It's not a question of "SAP-DB not being an ACID DBMS" (as some idiot claimed in another thread).
It's really largely a question of systemms integration, with a certain amount of "needs more marketing."
It was probably posted on comp.sources.unix or some such place back in the mid-80s.
If you run the Ruby script, as is, the result is thus:
#: Exception from service object: Invalid authorization key: xxxxxxxxxxxxxxx (SOAP::FaultError)
If somebody starts abusing a particular key, it's a no-brainer for Google to shut the key off.
And as for "not having to visit their site," remember that they're not doing huge amounts of banner ads. It's not totally evident that this "destroys" any of their business.
They still get to collect statistics on what queries come from where on what, which doesn't change terribly much whether they're receiving queries as HTML FORMs or XML SCHEMAs, and there's only a little reason for them to care about folks receiving back HTML versus XML
There are but weeks to go; time to start reviewing other 04/01 RFCs for further inspiration....
PDF is a specification on which Apple based their own scheme, Quartz.
There is no such thing, in formal terms, as "Display PDF." Neither Apple nor Adobe use that name. Apple calls their thing (which, as near as can be told, has NO Adobe encumbrances) Quartz. Adobe has a document format that they call PDF, but nothing that they call "Display PDF."
On the other hand, if you read a PDF document using acroread, you do have to have a valid license from Adobe
What happened with DPS was that Adobe was not prepared to continue licensing it to Apple under terms they were prepared to agree on. The natural result was that Apple went away and implemented their own thing, namely a "Display PDF" renderer, called Quartz.
The notion that this has much of anything to do with the formats is just silly...
For those that think GNOME and KDE are too big and bloated, this is moving towards being usable for some applications.
Keeping relevance, if L. Peter Deutsch didn't win, the somewhat-inadequacy of DGS work that the FSF contracted for might very well be part of the reason...