use Perl

• XML Documents vs. SOAP APIs (Score:2)

  by ziggy (25)

  There's one significant difference between Google's XML results and Google's SOAP API: the XML results gave you a document and left you on your own; the SOAP API gives you pre-digested data structures.

  Giving everyone the same (poorly-tagged) XML document left them on a very low plateau: everyone who wanted to use the XML Search needed to write a parser for this document (or re-use someone else's). It's a nice solution, but only if you're not very lazy or just like XML. [*]

  The SOAP solution on the other
  • Re:XML Documents vs. SOAP APIs (Score:2)

    by Matts (1087)

    So this is mostly because other languages XML parsers suck? If you stuck something containing <results><result... into XML::Simple, you'd get a simple array-ref. So this becomes as simple as XMLin("http://google.com/xml?q=foo") (assuming you've turned on XML::Parser's LWP support).
    • Re:XML Documents vs. SOAP APIs (Score:2)

      by ziggy (25)

      So this is mostly because other languages XML parsers suck?

      I don't know if it's an issue of suckiness or not. XML::Simple or a tree-based parser still shows an XML-centric data structure. SOAP shows an application-centric data structure for any application using SOAP. While you have to ignore a lot of bogosity to get to the <result> element in a SOAP envelope, once your SOAP library has done that (on your behalf), you're left with something that (likely) maps very well to your problem space, r
      • Re:XML Documents vs. SOAP APIs (Score:2)

        by Matts (1087)

        What has me wondering about SOAP, is why we didn't end up with CORBA over HTTP (rather than IIOP). I guess ultimately it was the pig-headedness of the OMG that slowed CORBA down - if they'd had some foresight into firewall smashing, and leveraging the web, they may have won out.
        
        The sad fact is that SOAP is simply slow in Perl, so for performance SOAP applications you need to use another language. And that's when it stops being fun.
• SOAP sucks (Score:2)

  by ask (83)

  This is a perfect application for doing it "the old way".
  
  The old way we could have had caching and all sorts of neat things too for free. And they could have used standard http auth for authentication instead of having to reinvent that too.
  
  

  --
  

  -- ask bjoern hansen [askbjoernhansen.com], !try; do();
  • Re:SOAP sucks (Score:2)

    by ziggy (25)

    But HTTP authentication is soooo second millenium. All the cool kids are doing neat-o kewl SOAP stuff now! And all of the k-rad SOAP APIs support the new widgets, not the krufty old HTTP auth.

    :-)
• Not XML, HTTP (Score:2)

  by darobin (1316)

  I don't think that the guy that made the schema they were using hated XML. In fact, I'm sure it's the same person that made the SOAP API (at least, I wouldn't be surprised.

  Thinking that XML is verbose is no reason to use unreadable element names. The reason the schema was designed that way was for the same reason form parameters are unreadable in most search engines: if you get several million requests a day, naming a form parameter q instead of query gains you some bandwidth. In fact, it gains you

  --
  

  -- Robin Berjon [berjon.com]
  • Re:Not XML, HTTP (Score:2)

    by koschei (147)

    I think some Perl users wouldn't really care if they had SOAP or XML. All that matters is that they can:
    
    use WWW::Search::Google::type;
    
    my $results = WWW::Search::Google::type->new($key, $query);
    
    etc.
    
    where type is either SOAP or XML or HTML or whatever.
    
    Heck, even with the type being transparent. You just specify that you want to use Google, and it picks the protocol it can use dependent upon what modules the user has installed.
    
    So long as there's a nice package that someone has written and they all pre

    --
      ---ict / Spoon
    • Re:Not XML, HTTP (Score:2)

      by Matts (1087)

      I guess the difference is that Java and .NET people don't have CPAN. So they'd either expect Google to release a package for doing the queries - one each for Java and .NET, or they'll simply prefer the SOAP way. I think since Google would probably prefer not to develop APIs for different languages then SOAP is more appealing to them.
      
      One thing that intruiges me though is the possibility to do server-side XSLT so that you can provide both a SOAP API and a plain XML API, from the same server using the same co
      • Re:Not XML, HTTP (Score:2)

        by koschei (147)

        How processing time efficient would that be compared to having two separate ones?
        
        Just curious since I am sure Google like to keep things efficient processing-wise.

        --
          ---ict / Spoon
        • Re:Not XML, HTTP (Score:2)

          by Matts (1087)

          I don't know. Ever heard of Moore's law ;-)
          
          I doubt it would be terribly efficient. But it might be fun to find out.