Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Google + SOAP

 [1/74] from: sunandadh:aol at: 7-Apr-2002 18:28


Anyone any idea how to turn this short Ruby program in Rebol? http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/37623 It's an experimental API to the Google database -- could be a killer add on. But I don't know SOAP hardly at all, and I don't know Ruby. Do we have the ability at all? Sunanda.

 [2/74] from: al:bri:xtra at: 8-Apr-2002 12:47


Sure! Just write: do %SOAP.r :D Andrew Martin No, it's not on my site... ICQ: 26227169 http://valley.150m.com/

 [3/74] from: gchiu:compkarori at: 8-Apr-2002 21:45


On Sun, 7 Apr 2002 18:28:43 EDT [SunandaDH--aol--com] wrote:
> Anyone any idea how to turn this short Ruby program in > Rebol?
<<quoted lines omitted: 4>>
> Ruby. Do we have the > ability at all?
I wrote an article on Soap in Rebol. check the Rebzine. -- Graham Chiu

 [4/74] from: gchiu:compkarori at: 19-Apr-2002 8:03


On Sun, 7 Apr 2002 18:28:43 EDT [SunandaDH--aol--com] wrote:
> It's an experimental API to the Google database -- could > be a killer add on.
The APIs have now been published http://www.google.com/apis/ -- Graham Chiu

 [5/74] from: carl:rebol at: 19-Apr-2002 20:32


I think it's good to invent some smart way to make Web Services easier via REBOL. So, that's the best way to get there from here? For example: REBOL Google search: Do-Google-Search [ key: #00000000000000000000000000000000 q: "shrdlu winograd maclisp teletype" start: 0 maxResults: 10 filter: true restrict: none safeSearch: false lr: none ie: 'latin1 oe: 'latin1 ] XML SOAP Google search: <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doGoogleSearch xmlns:ns1="urn:GoogleSearch" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <key xsi:type="xsd:string">00000000000000000000000000000000</key> <q xsi:type="xsd:string">shrdlu winograd maclisp teletype</q> <start xsi:type="xsd:int">0</start> <maxResults xsi:type="xsd:int">10</maxResults> <filter xsi:type="xsd:boolean">true</filter> <restrict xsi:type="xsd:string"></restrict> <safeSearch xsi:type="xsd:boolean">false</safeSearch> <lr xsi:type="xsd:string"></lr> <ie xsi:type="xsd:string">latin1</ie> <oe xsi:type="xsd:string">latin1</oe> </ns1:doGoogleSearch> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Your thoughts? -Carl At 4/19/02 08:03 AM +1200, you wrote:

 [6/74] from: rishioswal:yaho:o at: 19-Apr-2002 22:50


Yes! I couldn't agree more! (the way you put it makes it hard to argue :) ) However... couldn't we have both ways without complicating the language?.. just a thought rishi --- Carl Sassenrath <[carl--rebol--com]> wrote:

 [7/74] from: brett:codeconscious at: 20-Apr-2002 19:28


Hi Carl, I think your parameter block example nicely demonstrates again REBOL's powerful expression ability. The question I think then is - how does Do-Google-Search come about? I'm a "babe in the woods" in my understanding of web services and the XML namespace obligations, but I suspect that do-google-search should be manufactured by some smart REBOL factory function that takes the WSDL specification as input. Maybe someone else can comment on the feasability of this. On a different tangent I can envisage two REBOL web service client scenarios: (1) user-agent (2) IOS server on behalf of IOS users: (1) The user-client would best use something like do-google-search. That is do-google-search is a proxy/stub for the web service. (2) The IOS server-client (ios<--->non-ios) might want to make asynchronous calls to a web service before returning/sending results to an IOS client in a situation where possibly many webservice calls are made on behalf of IOS users - a message router model (I think). Perhaps REBOL schemes can also be useful here? Brett. ----- Original Message ----- From: "Carl Sassenrath" <[carl--rebol--com]> To: <[rebol-list--rebol--com]> Sent: Saturday, April 20, 2002 1:32 PM Subject: [REBOL] Re: Google + SOAP
> I think it's good to invent some smart way to make Web Services easier via
REBOL. So, that's the best way to get there from here? For example:
> REBOL Google search: > Do-Google-Search [
<<quoted lines omitted: 12>>
> <?xml version='1.0' encoding='UTF-8'?> > <SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">

 [8/74] from: gavin_mckenzie:fastmail:fm at: 20-Apr-2002 13:11


Carl, I love REBOL, and I love XML. Well, ok...so my paycheques come in large part from XML; hence, maybe there's a difference. I'm sorta feeling like your email is comparing a web protocol with a programming language. It feels like apples and oranges. REBOL is good because it has networking built-in, thus I don't have to hand-code HTTP -- I can just do a read http://... HTTP remains a good and successful protocol, and REBOL is a great language. You're not comparing SOAP/XML to REBOL though, are you? That wouldn't seem to be a fruitful exercise. One is a protocol and meta-markup-language, and the other is a programming language. They're both good at what they do. Ok, so maybe your point is that creating functions like Do-Google-Search remove the need to hand-code the SOAP/XML protocol? Ok, that's good, and probably self-evident. That's what we use programming languages for -- to construct reusable bits of code that do heavy-lifting on our behalf. Presumably that a C++ or Java function like doGoogleSearch(...) would illustrate your point equally well? Sorry if I've completely missed the gist of your email. Maybe I need another cup of coffee to clear my head. Gavin. -- Gavin McKenzie http://www3.sympatico.ca/gavin.mckenzie [gavin_mckenzie--fastmail--fm] http://fastmail.fm

 [9/74] from: petr:krenzelok:trz:cz at: 20-Apr-2002 16:52


Gavin McKenzie wrote:
>Carl, >I love REBOL, and I love XML. Well, ok...so my paycheques come in
<<quoted lines omitted: 19>>
>another cup of coffee to clear my head. >Gavin.
Hello Gavi, what was your post about? :-) Are you suggesting proper XML support is needed? I think that if RT does not want to produce better XML support in the language, they could license your stuff? Can your scripts be used to parse SOAP, WSDL, UDDI? Or do they use any kind of aproach your scripts are not capable of parsing? I remember you told me something like your scripts are not correctly working with XML schemas, as this is rather complex thing? Thanks a lot, -pekr-

 [10/74] from: andreas:bolka:gmx at: 20-Apr-2002 17:10


Saturday, April 20, 2002, 5:32:00 AM, Carl wrote:
> I think it's good to invent some smart way to make Web Services > easier via REBOL.
Most people on the list will agree to that :)
> So, that's the best way to get there from here? For example:
I think you've got an important typo here, that explains the (imho) strange replies. Shouldn't it be "So, WHAT'S the best way to get there from here?" ? I'm very interested in the "best way" too, so go on dear REBOLers and reply as if this was the question :) -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [11/74] from: greggirwin:mindspring at: 20-Apr-2002 9:43


Hi Gavin, First of all, I'm not an XML guy (and have no desire to be). I think being able to convert REBOL data and blocks to XML, maybe with a smart transformer that takes a DTD as its guide or something, is something that will be very useful for dealing with those that choose to use XML. A great opportunity no doubt. << You're not comparing SOAP/XML to REBOL though, are you? That wouldn't seem to be a fruitful exercise. One is a protocol and meta-markup-language, and the other is a programming language. They're both good at what they do. >> You certainly can't compare them IMO. SOAP and XML are two different things. XML is a markup language and REBOL is a programming language, if you categorize them that way. SOAP is just an XML dialect. There's a big difference though, in how they "fit" into their respective classifications. XML, correct me if I'm wrong, is *not* good at specifying programs. REBOL, OTOH, is *very* good at specifying and processing data that may or may not have other information (e.g. markup) associated with it. I.e. REBOL is a programming language that understands data. While you can specify data pretty easily in native REBOL format (much more easiy than in XML IMO), the real power comes from being able to express data in dialects that REBOL programs can understand. Just my 2 cents. --Gregg

 [12/74] from: chris:langreiter at: 20-Apr-2002 17:49


> You're not comparing SOAP/XML to REBOL though, are you? That wouldn't > seem to be a fruitful exercise. One is a protocol and > meta-markup-language, and the other is a programming language. They're > both good at what they do.
XML and the XML-related standards are basically a set of representational constraints, as is every language. REBOL, when used purely as data representation language (i.e. without any of its non-declarative/procedural/functional capabilities), is indeed very similar in capabilities to XML. What lacks, for example, is Unicode, but otherwise you can most easily translate any piece of XML into a REBOL representation. But I can do that as well with Java! , you'll say, and right you are, after all, that's the point of XML. However - and that is the critical point, IMO, if you look at the REBOL representation and the Java object serialization side-by-side, you'll see that while the resulting serialization is practically incomprehensible to humans without tool support, the REBOL one is actually simpler than the XML form we started with. <person> <name>Chris</name> <age>22</age> </person> person [name "Chris" age 22] BTW, at http://www.langreiter.com/rebol/google/ you can find a simple wrapper around some functions the Google API provides, along with useful features like result caching. If you're interested in SOAP, you might also be interested in XML-RPC, which is the simpler predecessor of SOAP (and avoids practically all of the problems SOAP people have to cope with due to the higher level of complexity). http://earl.strain.at/space/rebXR Carl, one question, however, remains: What is the "official RT way" to write high-performance, concurrent servers in REBOL? (And no, Rugby is not an option, because it blocks when executing long-running functions). I have found no completely compelling way to do so yet. Best regards, -- Chris -- http://www.langreiter.com

 [13/74] from: jason:cunliffe:verizon at: 20-Apr-2002 11:24


> Do-Google-Search [ > key: #00000000000000000000000000000000
<<quoted lines omitted: 8>>
> oe: 'latin1 > ]
Nice! .. but one might need an option to include schema spec xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> ..and how about
>> Do-Google-Search/soap ;current >> Do-Google-Search/beep
; Assuming google may end up with various protocols to access its API, perhaps built with beep http://www.beepcore.org/beepcore/home.jsp http://www.beepcore.org/beepcore/about_qanda.jsp
>> Do-Google-Search/wsdl >> Do-Google-Search/soap/sendxml
;Prepares SOAP xml Google query for use by other. This refinemetn returns the correct xml-formatted request
>> Do-Google-Search/xmlreply
;Returns search as XML formatted
>> Do-google-Search/rebol
; The default - returns results as REBOL object block ./Jason

 [14/74] from: gavin_mckenzie:fastmail:fm at: 20-Apr-2002 16:44


Petr, On Sat, 20 Apr 2002 16:52:25 +0200, "Petr Krenzelok" <[petr--krenzelok--trz--cz]> said:
> what was your post about? :-) Are you suggesting proper XML support is > needed?
Oh dear...have I become a one-trick pony? A broken record? Actually, I wasn't intending to revive that old rant. I'm sure I've bored people enough with it over the last couple of years.
> I think that if RT does not want to produce better XML support > in the language, they could license your stuff? Can your scripts be > used to parse SOAP, WSDL, UDDI?
Yes, maybe, sort-of...it depends on just how robust of a solution is required. My scripts aren't suitable for creating a bulletproof-grade solution; for a start my parser lacks namespace support (though I've procrastinated on finishing namespace support that I started eons ago). Further, I don't provide a script to reverse my xml-to-object conversion. Though I've got a script 90% done. Of course, as we know, it is really easy to get software to the 90% completion stage isn't it? Oh...one day I'll finish them...or so I keep telling myself. We do know that there are fine REBOL scripts out there to do XML-RPC, and I *think* SOAP. But I'd bet that all of those scripts (including my own) to be fragile; subject to breaking outside the common cases of XML, or SOAP, or XML-RPC. Nonetheless, within a controlled environment, they may be a sufficient solution.
> Or do they use any kind of aproach your > scripts are not capable of parsing? I remember you told me something > like your scripts are not correctly working with XML schemas, as this > is rather complex thing? >
Namespaces, schema, etc. You can cook up a solution that doesn't absolutely require these things, but it helps to have support for them. Schemas: yep, they're real complex alright. Gavin. -- Gavin McKenzie http://www3.sympatico.ca/gavin.mckenzie [gavin_mckenzie--fastmail--fm] http://fastmail.fm

 [15/74] from: gavin_mckenzie:fastmail:fm at: 20-Apr-2002 17:22


Gregg, Yes, I agree with all that you have said. Gavin. On Sat, 20 Apr 2002 09:43:46 -0600, "Gregg Irwin" <[greggirwin--mindspring--com]> said:
> Hi Gavin, > First of all, I'm not an XML guy (and have no desire to be). I think
<<quoted lines omitted: 34>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Gavin McKenzie http://www3.sympatico.ca/gavin.mckenzie [gavin_mckenzie--fastmail--fm] http://fastmail.fm

 [16/74] from: gavin_mckenzie:fastmail:fm at: 20-Apr-2002 18:10


Christian, On Sat, 20 Apr 2002 17:49:48 +0200, "Christian Langreiter" <[chris--langreiter--com]> said: [snip]
> XML and the XML-related standards are basically a set of > representational
<<quoted lines omitted: 3>>
> similar > in capabilities to XML.
Indeed.
> What lacks, for example, is Unicode,
Yes...lack of Unicode support in REBOL is something that I've always found extremely surprising.
> but otherwise > you can most easily translate any piece of XML into a REBOL > representation. > "But I can do that as well with Java!", you'll say
Actually, I wouldn't say that. Or, at least I wasn't implying that. I was trying to figure out what Carl was saying. I expect that he was musing about a Do-Google-Search function that accepted a single block parameter expressing the Google-API parameters as set-word/value pairs. This presumably isn't much different than a C++/Java method doGoogleSearch(...) except that with REBOL you have the ability to name your parameters, which is something that I *do* like very much. I wasn't looking to compare REBOL to other languages; that's an invitation to a flame-fest, and besides...I do love REBOL.
> , and right you are, after > all, that's the point of XML. However - and that is the critical point,
<<quoted lines omitted: 5>>
> one > is actually simpler than the XML form we started with.
True...but I assume that Carl's (imaginary?) Do-Google-Search function is going to produce an XML/SOAP message anyway, given that this is the requirement of the Google API. He's not actually going to drop a REBOL block or object on the line and ship it out to Google, unless he's persuaded Google to provide a REBOL interface. That *would* be cool, but I don't think that's where this is going. So, again, I don't believe we were talking about REBOL as serialization format; his code fragment clearly (to me) looks like a function that accepts a block as a param. Did I misread the code? Certainly he seemed to be comparing some REBOL code to an XML serialization format of a SOAP message. Hence, my confusion and issue about comparing apples and oranges. Carl's messages can sometimes (often?) be a tease, sometimes Yoda-like. I don't think this one is any different.
> <person> > <name>Chris</name> > <age>22</age> > </person> > > person [name "Chris" age 22] >
There have been (somewhat misguided) efforts by some to create an even simpler alternative to XML. Some LISP/Schema people (to which REBOL bears a resemblance) dis' XML and yearn for a S-expr solution. You could just as easily create an XML fragment like: <person name="Chris" age="22"/> That doesn't seem worse (to me) than the REBOL syntax. But again, I wasn't looking to be drawn into a comparison game. If anything, I was troubled that Carl might be engaging in a comparison game.
> BTW, at http://www.langreiter.com/rebol/google/ you can find a simple > wrapper around some functions the Google API provides, along with > useful > features like result caching. >
Cool. I'll check it out.
> If you're interested in SOAP, you might also be interested in XML-RPC, > which > is the simpler predecessor of SOAP (and avoids practically all of the > problems SOAP people have to cope with due to the higher level of > complexity).
Yes, though XML-RPC has issues of its own. And there are those, under the banner of "REST", that belive this whole XML-RPC / SOAP business is folly; that the HTTP verbs of GET/PUT/POST/DELETE combined with URIs are sufficent and superior. See Paul Prescod's article at: http://www.xml.com/pub/a/2002/02/06/rest.html
>[snip] >
Gavin. -- Gavin McKenzie http://www3.sympatico.ca/gavin.mckenzie [gavin_mckenzie--fastmail--fm] http://fastmail.fm

 [17/74] from: g:santilli:tiscalinet:it at: 20-Apr-2002 21:08


Hi Gavin, On Saturday, April 20, 2002, 3:11:19 PM, you wrote: GM> I'm sorta feeling like your email is comparing a web protocol with a GM> programming language. It feels like apples and oranges. Actually, I think Carl was referring to XML and REBOL as data representation languages. Both can be used for representing data; REBOL can be used to represent "actions" too, because it has a built-in interpreter that is able to execute some data if it has a specific format. I prefer REBOL to XML. It is much more clean and readable. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [18/74] from: chris:langreiter at: 21-Apr-2002 4:11


> Carl's messages can sometimes (often?) be a tease, sometimes Yoda-like. > I don't think this one is any different.
Heh ;-) I have to agree.
> <person name="Chris" age="22"/>
You're absolutely right. I don't want to "discredit" XML either, while it and its surrounding standards in their entirety may well be representative of the semi-baroque bloat commitees happen to produce, it is the one hierarchical data serialization format the world happens to have standardized on. And that there is such a standard at all, that's most definitely a very good thing. It could have been way way way worse and we'd have to parse (binary!) hierarchical OLE documents if you-know-who got its way ;-)
> Yes, though XML-RPC has issues of its own. And there are those, under > the banner of "REST", that belive this whole XML-RPC / SOAP business is > folly; that the HTTP verbs of GET/PUT/POST/DELETE combined with URIs > are sufficent and superior.
In many cases (especially when the "parameter list" is flat, reasonably short and can therefore be easily serialized to an URI), REST (fancy new name for pretty old concepts, ain't it?) is IMO more transparent. What I like about XML-RPC is that it defines a lowest common denominator of data types that can be exchanged, i.e. they can be mapped to native data types of pretty much any language with zero additional overhead for the user (me! ;-). Best regards, -- Chris

 [19/74] from: gchiu:compkarori at: 21-Apr-2002 14:44


On Fri, 19 Apr 2002 20:32:00 -0700 Carl Sassenrath <[carl--rebol--com]> wrote:
> I think it's good to invent some smart way to make Web > Services easier via REBOL. So, that's the best way to get > there from here? For example: >
Here's a quick hack....( no error checking ) do http://www.compkarori.co.nz/reb/google.r do-google-search "api license key" "rebol" 0 10 true "" false "" "latin1" "latin1" No of results 34500 urls 10 titles 10 snippets 10 url: http://www.rebol.com/ url: http://www.rebol.com/downloads.html url: http://www.rebol.org/ url: http://www.rebolpress.com/ url: http://www.rebolforces.com/ url: http://www.webtechniques.com/archives/1999/09/junk/ url: http://vydra.net/rebol-unit/rebol-unit.html url: http://www.dartmouth.edu/~grossman/REBOL/ url: http://www.obscure.dk/rebol/ url: http://www.abooks.com/rebol/
>>
You need to apply for your own api license key and plug it in as above. -- Graham Chiu http://www.compkarori.com/cgi-local/index.r

 [20/74] from: al:bri:xtra at: 21-Apr-2002 20:29


Carl wrote:
> I think it's good to invent some smart way to make Web Services easier via
REBOL. Here's one way: http://hci.stanford.edu/~winograd/shrdlu/code/manual And here's some students attempts at decoding it: http://acm.cs.umr.edu/shrdlu/ I'm fairly sure the mailing list is very, very dead. The links are interesting though, particularly: http://world.std.com/~pitman/Papers/Special-Forms.html Andrew Martin Am I still on topic? Yes, I think so... ICQ: 26227169 http://valley.150m.com/

 [21/74] from: al:bri:xtra at: 21-Apr-2002 19:46


Carl wrote:
> So, that's the best way to get there from here?
And another Carl's software produced: No of results 15 urls 6 titles 6 snippets 6 url: http://www.dashes.com/anil/ url: http://www.dashes.com/anil/index.php?nynmnf.php url: http://www.anildash.com/ url: http://hci.stanford.edu/winograd/shrdlu url: http://hci.stanford.edu/cs147/examples/shrdlu/ url: http://www.trentu.ca/csd/newsarchives/trentu/csp/cr350/79 :) Andrew Martin Busy reading Yoda's advice... ICQ: 26227169 http://valley.150m.com/

 [22/74] from: sunandadh:aol at: 21-Apr-2002 5:39


Graham:
> Here's a quick hack....( no error checking ) > > do http://www.compkarori.co.nz/reb/google.r
Thanks! That answers my original question. Super-cool stuff!! Though you didn't say so, you script does not need the WSDL/Google API download. So it needs just under 270K as a download to work (256k for Rebol/core plus 12K for your two scripts). Maybe Rebol is too darned _small_ for the web to notice <g> Sunanda.

 [23/74] from: petr::krenzelok::trz::cz at: 21-Apr-2002 11:52

Rebol marketing, Hifh performance, concurrent server (Was) Re: [REBOL] R


Christian Langreiter wrote:
>Carl, one question, however, remains: What is the "official RT way" to write >high-performance, concurrent servers in REBOL? (And no, Rugby is not an
<<quoted lines omitted: 3>>
>-- Chris >-- http://www.langreiter.com
Hi Chris, I think, that currently, there is no official RT's way. It is really sad seeing Holger's replies of a "we need you to pay for a certain feature". That's on one hand. On the second hand - we can be glad, that RT has actually some sales for IOS, are making some money, but are pretty busy. But wasn't it expectable? What kind of support do you want to provide, with some 5 or so developers? There are only two ways - - open source, or at least opened enough language (shell and library components for free), browser plug-ins for View, gaining critical mass of users ... and charge for the money in certain areas later. It would come! - as ppl would start to use language in areas, where currently language can't be used, or licensing policy is making it rather difficult. - RT doesn't want to go the first way, maybe just because they need to live from something - so - they need to sell products. If you sell your products, you need to provide certain level of tech support. Having 5 programmers on board, you can't do too much in the technology development area. I think, that things like Unicode will come, as well as Rebol Core 3.0 is imo already planned, async networking is being worked on, etc etc. RT already told us, that they do want to enhance Rebol technology, but will do so only when time permits them to do so. Of course, Rebol user-base would prefer the first way to go, as it is clear some platforms are being left, and others will not come (QNX), if there is no business need for it - wrong aproach imo, but well .... The different situation would be, if e.g. IBM would invest 100 mil USD in RT, because they just like the technology :-) So, now to Rugby - imo RT don't want to take some "official way" right now - we will get low-level adaptation - async networking. That's all so far. Rugby can be used to non-blocking calls - rexec/deferred, or I just don't understand properly what do you mean. Other nice solution to the poblem should come in two or so months from one Rebol user here, and I think it is gonna be cool. Just can't say more right now, as it is not my business to do so .... :-) Cheers, -pekr-

 [24/74] from: gchiu:compkarori at: 22-Apr-2002 0:48

Re: Google + SOAP


On Sun, 21 Apr 2002 05:39:26 EDT [SunandaDH--aol--com] wrote:
> > Here's a quick hack....( no error checking )
I lied. I put in a little error checking :)
> > > > do http://www.compkarori.co.nz/reb/google.r > > Thanks! That answers my original question. Super-cool > stuff!! > > Though you didn't say so, you script does not need the > WSDL/Google API
I could have attempted to programmatically discover the syntax for the soap body as in the form displayed here ... http://www.compkarori.com/soap/index.shtml If you plug in the google wsdl file, my script does seem to produce something. But as it was, I had forgotten I had written the above, and did it manually!! :(
> download. So it needs just under 270K as a download to > work (256k for > Rebol/core plus 12K for your two scripts).
The scripts could be even smaller as the http-tools script has some other functionality not needed for this. -- Graham Chiu

 [25/74] from: gerardcote:sympatico:ca at: 21-Apr-2002 18:57


Hello Graham and other lovers of Google, Here follows an article and another reference about using the Google with the help of its API (for example using Google with an outliner for browsing). I got them today from the Dave Winer's Davenet Userland. It talks about Google, SOAP and the many uses Dave and others thought about when using the Google's APIs. Hope it will ignite some mind sparks to you and other REBOL users. Gerard ----- Message d'origine ----- De : DaveNet email <[dave--scripting--com]> À : DaveNet World <[davenet-world--scripting--com]> Envoyé : 21 avril, 2002 12:23 Objet : The Mind of Google
> DaveNet essay, "The Mind of Google", released on 4/21/2002;
9:18:17 AM Pacific.
> --------------------------------------------------------------
------------------------
> ***Carl Stork > > I had a long telephone conversation yesterday with Microsoft's
Carl Stork, who's on leave, after being the vice-president who worked with Micorosoft's hardware OEMs. Carl and I share a love for baseball, we both grew up in the NY metropolitan area, even though Carl is an American League fan, and my National League mind has never really understood the American League. But we get along really well, I always enjoy talking with Carl.
> We talked about a lot of things, music on the Internet, the
state of independent software developers in 2002, and swung around to the state of DaveNet. Carl observed that I wasn't writing as many pieces as I used to. I explained that's because most of the action is on my weblog [1] these days, it's a daily story, and to get the DaveNet group in the loop is something I rarely have the time to do these days.
> But the Google-Meets-SOAP story is an exception. Since I was
briefed well before-hand, I had time to get both flows ready, to explain the news, what it meant, and offer some insight into where I saw it going, through both channels. And today I'm pleased to report that we found what may be a killer app for the current Google-SOAP interface. I'm going to explain it briefly here, and offer pointers where you can experience it for yourself.
> > ***Outline browsers > > First, this is very much like something I played around with
in MORE in the 80s. We licensed a thesaurus. I wired it into the outliner. Type in a word. Double-click to see its synonyms. Repeat until the exploration is done. It was a great way to think up product names.
> Browsing Google in an outliner is similar, but also different,
because Google's database has a different kind of content.
> > ***The Mind of Google > > Open an outline window and enter the URL of a website that's
the seed of my exploration.
> Double-click. See the sites that are related to it. Pick one
of its subs. Double-click. Invariably it loops back to the place I came from, but gives me nine other related sites.
> It's a very simple way to crawl what I've come to think of as
The Mind of Google. It's remarkably insightful for a piece of software. For example, I crawled [2] my way to Dennis Ritchie's home page at Bell Labs. Ritchie is one of the inventors of the C programming language. Google relates his site to the sites of Bjarne Stroustrup, Don Knuth, Richard Stallman, Linus Torvalds, Andrew S. Tanenbaum, Steve Wozniak, Brian Kernighan and Ken Thompson. I'm not sure exactly what the common thread is, but they're all heroic developers who made significant contributions over many years to the technology and culture of computer programming.
> I spent a couple of hours digging around. So many things to
think about. So many puzzles. I came across the word telegraphy in dictionary.com as I was Google Outline Browsing, and found that many of the related pages were mine! Somehow it seems to have figured something out about me, or how I am perceived. It was at this point that I started to feel like I was interacting with something with a mind. Of course Google doesn't have one, but it does a fantastic job of tapping into our collective minds. In a sense Google is a global intellect, and I'm happy to report that the world has a good mind. Very interesting stuff.
> Where the HTML interface for Google is a quick in-and-out,
this is the contemplative side of Google, previously invisible, there was no user interface for it.
> I announced this new way of browsing Google on Scripting News,
and within a day, three other developers had similar browsers [3] in HTML, and of course others are welcome to do it in an outliner, which is where the interface works best, imho.
> Dave Winer > > [1] http://www.scripting.com/ > [2]
http://radio.weblogs.com/0001015/images/2002/04/20/gobscreen2.gi f
> [3]
http://www.soapware.org/directory/4/services/googleApi/applicati ons
> --------------------------------------------------------------
------------------------
> (c) Copyright 1994-2002, Dave Winer.
http://davenet.userland.com/.
> "There's no time like now." >
And the reference to using "Google Outlining" is now following below : http://www.soapware.org/directory/4/services/googleApi/applications

 [26/74] from: andreas:bolka:gmx at: 22-Apr-2002 18:00


Sunday, April 21, 2002, 2:48:04 PM, Graham wrote:
> I could have attempted to programmatically discover the syntax for > the soap body as in the form displayed here ... > http://www.compkarori.com/soap/index.shtml > If you plug in the google wsdl file, my script does seem to produce > something. But as it was, I had forgotten I had written the above, > and did it manually!! :(
Graham, those things look great. Are the avail to for download somewhere? -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [27/74] from: gchiu:compkarori at: 23-Apr-2002 9:38


Hi Andreas
> Graham, those things look great. Are the avail to for > download > somewhere?
Not at present. They were just experiments to see how far I could get parsing WSDL files using brute force :) As such, the scripts are a bit fragile ( fails on complex datatypes ) and very ugly, and not suitable for public viewing! I was hoping to get back to them one day using Gavin's xml libraries but ran out of time. It is interesting to see ( from the list of services available in the drop down list ) though how many SOAP services have disappeared over the last year! -- Graham Chiu

 [28/74] from: brett:codeconscious at: 23-Apr-2002 15:05


So Carl wrote (apart from the fixed typo):
> I think it's good to invent some smart way to make Web Services > easier via REBOL. So, what's the best way to get there from here?
Are there no concrete answers to that - or did I miss something I shouldn't have? Any road-map type answers? Brett.

 [29/74] from: bry:itnisk at: 23-Apr-2002 9:05


since SOAP is an xml dialect generally sent via http(although in the current incarnation of the format it can be sent via any protocol, according to w3) and as there are a number of other examples out there of xml made to hitch on the back of a protocol, generally http(among which are xml-rpc, beepcore, and webDAV) it seems to me there should be at least some worktools specified somewhere, with clear tutorials on their use, for binding xml data to a protocol.

 [30/74] from: dockimbel:free at: 23-Apr-2002 11:35


Here's how web services could be supported by REBOL : * code example : service: open soap://api-ab.google.com/search/beta2/GoogleSearchService res: insert service [ doGoogleSearch [ key: #00000000000000000000000000000000 q: "shrdlu winograd maclisp teletype" start: 0 maxResults: 10 filter: true restrict: none safeSearch: false lr: none ie: 'latin1 oe: 'latin1 ]] close service * Of course a short 'read call should also be possible : res: read soap://api-ab.google.com/search/beta2/GoogleSearchService [ doGoogleSearch [ key: #00000000000000000000000000000000 q: "shrdlu winograd maclisp teletype" start: 0 maxResults: 10 filter: true restrict: none safeSearch: false lr: none ie: 'latin1 oe: 'latin1 ] ] I like this one a lot! :-) * all XML stuff should be kept hidden in the 'soap scheme. * on opening the 'soap port, port/locals will be loaded with all available methods found in the WSDL file. The functions "spec" could be stored like this :
>> probe service/locals
[ doGoogleSearch [ key string! q string! start integer! maxResults integer! filter logic! restrict string! safeSearch logic! lr string! ie string! oe string! ] doGetCachedPage [...] doGetSpellingSuggestion [...] ] or if you prefer : [ Do-Google-Search [...] Do-Get-Cached-Page [...] Do-Get-Spelling-Suggestion [...] ] Maybe we could also use 'help to pretty print these infos. (>> help service) * The 'soap scheme should also take care of arguments conversion. For example : key: #000... => string! => "000..." restrict: none => string! => "" * if you want a wrapping func in the global context, just do : Do-Google-Search: func [data [block!]][ read soap://api-ab.google.com/search/beta2/GoogleSearchService reduce ['doGoogleSearch data] ] My 0,02eu... -DocKimbel. Carl Sassenrath wrote:

 [31/74] from: dockimbel:free at: 23-Apr-2002 13:27


Oops, i've left a little bug : Nenad Rakocevic wrote:
[...]
> res: read soap://api-ab.google.com/search/beta2/GoogleSearchService [
[...]
> Do-Google-Search: func [data [block!]][ > read soap://api-ab.google.com/search/beta2/GoogleSearchService reduce ['doGoogleSearch data] > ]
Should be : ...read join soap://api-ab.google.com/search/beta2/GoogleSearchService? mold [... -DocKimbel.

 [32/74] from: maarten:koopmans:surfnet:nl at: 23-Apr-2002 13:47


I second this. Anybody coding ;-)

 [33/74] from: gchiu:compkarori at: 24-Apr-2002 8:35


On Tue, 23 Apr 2002 11:35:44 +0200 Nenad Rakocevic <[dockimbel--free--fr]> wrote:
> Here's how web services could be supported by REBOL : > > * code example : > > service: open soap://api-ab.google.com/search/beta2/GoogleSearchService
what does close service achieve then? -- Graham Chiu

 [34/74] from: rishioswal:yaho:o at: 23-Apr-2002 13:41


This is great but my first thought is to use the wrapper function name: google instead of do-google-search You could probably also use google with refinements for additional features... rishi --- Maarten Koopmans <[Maarten--Koopmans--surfnet--nl]> wrote:

 [35/74] from: g:santilli:tiscalinet:it at: 23-Apr-2002 23:22


Hi Maarten, On Tuesday, April 23, 2002, 1:47:14 PM, you wrote: MK> I second this. Anybody coding ;-) Didn't Nenad just volunteer? <evil grin> ;-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [36/74] from: dockimbel:free at: 24-Apr-2002 1:32


Hi Graham, For now, nothing special, it just closes the opened port. Remember that REBOL ports are just an abstraction for virtual series, they don't necessarily mean that you're using tcp/ip connections. In this case, the real http connection is closed in the 'insert call. So, 'close here doesn't mean we're closing a tcp/ip connection, it just tell the handler to free his ressources (for example, set to 'none all the XML parsing stuff and do a 'recycle) Just a though: When you use the open/insert/close approach you can call several remote methods without having to parse the WSDL file each time. This is not true for 'read calls...unless web services are globally managed as a list of cached port! values that could be reused when opening the 'soap scheme. This sounds better but will eat more memory. Maybe the /direct refinement of 'open and 'read could be used to tell the 'soap scheme to use the cache or not... -DocKimbel. Graham Chiu wrote:

 [37/74] from: cybarite:sympatico:ca at: 23-Apr-2002 16:27


Doc Kimbel, Will you help with this delivery if everyone pushes?

 [38/74] from: gchiu:compkarori at: 24-Apr-2002 11:44


> Here's how web services could be supported by REBOL : > * code example :
<<quoted lines omitted: 12>>
> ]] > close service
How about, as an alternative, ... google: to-soap http://api.google.com/GoogleSearch.wsdl google/doGoogleSearch [ key q ... ] google/doSpellingSuggestion [ .. ] google/goGetCachedPage [ .. ] ? -- Graham Chiu

 [39/74] from: dockimbel:free at: 24-Apr-2002 1:47


Sure Rishi, i also prefer to keep it simple but i was just re-using Master Yoda's example to be more clear. ;-) -DocKimbel. Rishi Oswal wrote:

 [40/74] from: gchiu:compkarori at: 24-Apr-2002 13:47


Hi Nenad, On Wed, 24 Apr 2002 01:32:10 +0200 Nenad Rakocevic <[dockimbel--free--fr]> wrote:
> Just a though: > When you use the open/insert/close approach you can call > several remote methods without > having to parse the WSDL file each time. This is not true > for 'read calls...unless web
I guess what I was thinking was that you seem to be implying that the wsdl file should be opened each time the the virtual port is opened, whereas with a stable SOAP service, you really only need to do it the once. You could for instance create an object from the wsdl file, and store it locally. But I guess the added value in opening a virtual port is to check whether the service still exists! Soap services seem to be pretty emphemeral in my experience. -- Graham Chiu

 [41/74] from: rebol:optushome:au at: 24-Apr-2002 19:28


Gabriele, Nenad let get this project running on Elite or Developer. We can collate resources and contributions there. Cheers, Allen K

 [42/74] from: dockimbel:free at: 24-Apr-2002 12:48


I can help with the code, but it seems to me that's a little bit premature to jump in the inplementation without a deeper and more complete analyse. Coding is the easiest part in this kind of project. Let's try to first get some consistent and clear vision for every aspects of webs-ervices. -DocKimbel. Mike Myers wrote:

 [43/74] from: dockimbel:free at: 24-Apr-2002 13:43


Hi Graham, Graham Chiu wrote:
> How about, as an alternative, ... > > google: to-soap http://api.google.com/GoogleSearch.wsdl > > google/doGoogleSearch [ key q ... ] > google/doSpellingSuggestion [ .. ] > google/goGetCachedPage [ .. ]
Soap is a protocol, so i prefer write it like this : google: read soap://api.google.com/GoogleSeach google/doGoogleSearch [ key q ... ] google/doSpellingSuggestion [ .. ] google/goGetCachedPage [ .. ] Well, it's simple and clean, i like it. I would like to hear from others the pro/cons argument on this approach. -DocKimbel

 [44/74] from: dockimbel:free at: 24-Apr-2002 13:53


Graham Chiu wrote:
> Hi Nenad, > On Wed, 24 Apr 2002 01:32:10 +0200
<<quoted lines omitted: 10>>
> instance create an object from the wsdl file, and store it > locally.
Good idea. The object could contain the remote methods wrappers, their specs (args names & types), etc...
> But I guess the added value in opening a virtual port is to > check whether the service still exists! Soap services seem > to be pretty emphemeral in my experience.
That's right. A HTTP 'HEAD command should be enough to see if the service is still alive. -DocKimbel.

 [45/74] from: dockimbel:free at: 24-Apr-2002 14:07


Hi Gabriele, Argh! Trapped myself ! :P Well, adding web services support to REBOL is something that was crossing my mind for some times now, but it's currently not on high priority. Before starting to work on it, i would like to know if RT has plans to implement an enhanced XML parser/builder at mezzanine or native level ??? If not, my first task would be to make a complete and optimized one. (Maybe starting from Gavin's work) So, anyone from RT here to give us infos on what they're cooking for XML ? -DocKimbel Gabriele Santilli wrote:

 [46/74] from: petr:krenzelok:trz:cz at: 24-Apr-2002 14:13


Nenad Rakocevic wrote:
>I can help with the code, but it seems to me that's a little bit premature to jump >in the inplementation without a deeper and more complete analyse. Coding is the >easiest part in this kind of project. Let's try to first get some consistent and >clear vision for every aspects of webs-ervices. >
Let's get some protocol/communication framework first, right? We all want to live in better universe, no? :-)) -pekr-

 [47/74] from: robert:muench:robertmuench at: 24-Apr-2002 21:35


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 7>>
> Well, it's simple and clean, i like it. > I would like to hear from others the pro/cons argument on this approach.
Hi, like I do! Using a soap:// thing is really incredible nice :-)) Imagine all those .Netters and .One-I-dont-remember-how-this-sun-stuff-was-named working hard for web-services and you just write one line and show this is a demo. That's a killer line :-)). Robert

 [48/74] from: gchiu:compkarori at: 25-Apr-2002 9:30


On Wed, 24 Apr 2002 13:43:20 +0200 Nenad Rakocevic <[dockimbel--free--fr]> wrote:
> google: read soap://api.google.com/GoogleSeach > google/doGoogleSearch [ key q ... ]
<<quoted lines omitted: 3>>
> I would like to hear from others the pro/cons argument on > this approach.
Hi Nenad, This could assume that http is the default transport mechanism, and we could supply a refinement for alternatives eg google/goGetCachedPage/smtp [ .. ] and one of the reasons I prefer 'to-soap is that 'read is a native, and already overloaded. And if we use a mezzanine function, we can proceed regardless of what RT do, whereas 'read requires assistance from RT. But, if you really want to use 'read google: to-soap read soap://api.google.com/GoogleSeach.wsdl <G> -- Graham Chiu

 [49/74] from: dockimbel:free at: 27-Apr-2002 19:16


Hi Graham, Graham Chiu wrote:
> On Wed, 24 Apr 2002 13:43:20 +0200 > Nenad Rakocevic <[dockimbel--free--fr]> wrote: > > google: read soap://api.google.com/GoogleSeach > >
[...]
> This could assume that http is the default transport > mechanism, and we could supply a refinement for alternatives > > eg google/goGetCachedPage/smtp [ .. ]
I would rather make it that way : service: open soap://api.google.com/GoogleSeach insert service [use SMTP] then : service/locals/goGetCachedPage [...] .. or maybe : insert service [get all] google: copy service google/goGetCachedPage [...] ..
> and one of the reasons I prefer 'to-soap is that 'read is a > native, and already overloaded. And if we use a mezzanine > function, we can proceed regardless of what RT do, whereas > 'read requires assistance from RT.
Not totally true. 'Read is just a shortcut for open/insert/close. So, it can be supported when writing a scheme handler (see my work on MySQL). 'Read is fully polymorphic by definition.
> But, if you really want to use 'read > > google: to-soap read soap://api.google.com/GoogleSeach.wsdl
^^^^^^^ ^^^^^^ IMHO, this two additions shoud be useless. Regards, -DocKimbel.

 [50/74] from: gchiu:compkarori at: 28-Apr-2002 10:13


I note that Rebol Tech's new home page prominently features a graphic including SOAP ( SIMPLE object access protocol ) being contrasted against IOS as a technology being too complicated, in their new "Keep IT Simple" campaign. One conclusion that might be drawn from that is that SOAP and other XML technologies are not high on their "to do" list. -- Graham Chiu

 [51/74] from: chris:langreiter at: 28-Apr-2002 0:44


To quote Roger Sessions: SOAP [is] a rather confusing acronym, since it is neither simple, nor related to objects! http://www.objectwatch.com/FinalJ2EEandDotNet.doc Indeed, simple it is not. REBOL is. But there has not been an answer on my high-performance server quetsion yet - I just don't hope because there isn't any ;-) -- Chris

 [52/74] from: mla:itinko at: 27-Apr-2002 19:16


Having been to a live session with Roger Sessions it is my opinion that you have to take his opinions with a grain (or two) of salt. Between his half baked assumptions and unsubstantiated declarations I find some of his conclusions unsupported. I mean how does he come up with the conclusion that J2EE can't be run on commodity hardware? So what's so complex about SOAP?? It's merely an envelope of XML written in XML. Am I missing something here? Michael

 [53/74] from: petr:krenzelok:trz:cz at: 28-Apr-2002 2:25


Christian Langreiter wrote:
>To quote Roger Sessions: > >"SOAP [is] a rather confusing acronym, since it is neither simple, nor related to objects!" > >http://www.objectwatch.com/FinalJ2EEandDotNet.doc > >Indeed, simple it is not. REBOL is. > >But there has not been an answer on my high-performance server >quetsion yet - I just don't hope because there isn't any ;-) >
You haven't answered why you consider Rugby being blocking one ;-) I tried Ruby several times and it does some 250 RPC echos in a sec ... So, what is enough for you? :-) PS: what does your grin mean? Do you know something we don't? :-) Cheers, -pekr-

 [54/74] from: greggirwin:mindspring at: 28-Apr-2002 10:41


Hi Michael, << So what's so complex about SOAP?? It's merely an envelope of XML written in XML. Am I missing something here? >> Speaking from a position of relative ignorance, to me, XML itself is unwieldy and not good for human consumption. SOAP just adds another layer on top of it, which is no more human friendly than the original, indeed, it *is* the original as you point out. REBOL's dialecting approach is, IMHO, about a zillion times better than XML and SOAP. Interoperability is the only reason to even worry about it. Just had to jump in. :) --Gregg

 [55/74] from: mla:itinko at: 28-Apr-2002 17:23


Hi Gregg... Well since you jumped in I couldn't resist responding. XML may not be good for human consumption but isn't intended to be. It really is designed to make data more machine readable ! XML gives contextual meaning to data, allowing (relatively) stupid machines to intepret and manipulate the data more easily. End users should never be exposed to XML, only the resulting presentation from XSLT transforms into something like HTML (presented in a browser space, of course), or into visual objects presented in something like Flash. Comparing Rebol to XML is sort of like comparing Java to HTML. One is an action paradigm, the other is simply a markup paradigm. Rebol's dialecting may be neat but lets face it most people have never heard of it. Rebol is not likely to become an inter system standard anytime soon, anymore than Snobol is ever likely to become a popular language. My 2 cents. Michael

 [56/74] from: cybarite:sympatico:ca at: 28-Apr-2002 10:45


Sounds like violent agreement ... if you ask me... which no one did. If SOAP becomes ubiquitous, REBOL needs to be able to interoperate with it. Doing that elegantly using REBOL dialecting will make that easier for REBOL to excel.

 [57/74] from: greggirwin:mindspring at: 28-Apr-2002 16:48


Hi Michael, << End users should never be exposed to XML >> Maybe that's my problem. I'm an end user. :) I happen to develop software for a living, and have a couple hundred books related the subject on my shelves but I'm still an end user. << Comparing Rebol to XML is sort of like comparing Java to HTML. One is an action paradigm, the other is simply a markup paradigm. >> I agree! But SOAP is an action paradigm, right? ;) The other big difference is that REBOL, unlike most everything else out there is not *just* an action paradigm based language, it is a messaging language. The ability to understand data, without having to mark it up to make the machines happy is the big difference. Now, there has to be some kind of translator involved, the dialect in REBOL's case, but REBOL removes layers and layers of "fog" from the whole process. << Rebol's dialecting may be neat but lets face it most people have never heard of it. Rebol is not likely to become an inter system standard anytime soon, anymore than Snobol is ever likely to become a popular language. >> I agree that XML will likely enjoy at least a reasonable lifecycle in the market but it can't change the world the way that REBOL can. The catch with REBOL is that you don't have to define it as "a standard". It can work so covertly that people won't know, or care, what the technology is. It just understands. Now, that isn't going to happen overnight, but what excites me most about REBOL is how much I can do with it now, and I'm not even scratching the surface of what it can do. Thanks for the response! --Gregg

 [58/74] from: gchiu:compkarori at: 29-Apr-2002 11:34


> Interoperability is the only reason to even worry about > it.
And therein lies the rub. -- Graham Chiu

 [59/74] from: mla:itinko at: 28-Apr-2002 20:10


Gregg Well, I guess it's time to admit that being a complete Rebol newbie I haven't gotten "it" yet. I'm still thinking procedurally when I experiment in Rebol and haven't made the shift to the "Dialectic Paradigm" yet. Reminds me of my experiments in Prolog ;-) So in the meantime I can only stand at the base of the mountain wondering what you are all talking about when you say "the view from the top is fantastic!". Michael

 [60/74] from: greggirwin:mindspring at: 28-Apr-2002 18:46


Hi Michael, << Well, I guess it's time to admit that being a complete Rebol newbie I haven't gotten "it" yet. I'm still thinking procedurally when I experiment in Rebol and haven't made the shift to the "Dialectic Paradigm" yet. Reminds me of my experiments in Prolog ;-) So in the meantime I can only stand at the base of the mountain wondering what you are all talking about when you say "the view from the top is fantastic!". >> I'm still very much a newbie myself (8 months it seems). Someone once said there is a certain "zen" to good REBOLing and I find that more true as time passes. I'm only one or two rocks ahead of you I'm sure, but I can see that it's a tall mountain indeed. :) --Gregg

 [61/74] from: andreas:bolka:gmx at: 29-Apr-2002 18:08


Sunday, April 28, 2002, 2:25:04 AM, Petr wrote:
> Christian Langreiter wrote: >>But there has not been an answer on my high-performance server >>quetsion yet - I just don't hope because there isn't any ;-) > You haven't answered why you consider Rugby being blocking one ;-) I > tried Ruby several times and it does some 250 RPC echos in a sec ... > So, what is enough for you? :-)
i think chris' considers rugby beeing no option as it is not able to accept a concurrent call while it is processing one. 250 echo (!!!) calls / sec might be fine, but as soon as the funcs beeing called actually do something, you'll never get there ;) consider the following: we have two clients, let's call the peter and carla and we have a server (a rugby server) which exports a func called 'long-running-func'. to produce a result, this func takes 10 secs at average. peter calls long-running-func on server. 1 sec later, carla tries to call long-running-func on server too, but rugby is not able to accept calls in this stage. carla has to wait the average 10 seconds until peter's call finished. only then her call gets processed! chris' original question:
> "What is the "official RT way" to write high-performance, concurrent > servers in REBOL?"
the concurrent is the key! [maarten, no offense intended! i don't want to imply that this behaviour is rugby's fault] -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [62/74] from: petr:krenzelok:trz:cz at: 29-Apr-2002 21:18


Andreas Bolka wrote:
>Sunday, April 28, 2002, 2:25:04 AM, Petr wrote: >>Christian Langreiter wrote:
<<quoted lines omitted: 30>>
>[maarten, no offense intended! i don't want to imply that this >behaviour is rugby's fault]
No, it isn't Rugby's fault, sorry :-) Your scenario is of course correct, but replace Rugby and Rebol by Java, etc. - it's just the same. If some func takes 10 sec, then it takes 10 sec. Maybe using Java, it will be faster, but still blocking. So, what is the solution, what are implications? 1) I know where you are trying to point maybe - is that threading? Well, you don't need threading to help solve it - you can launch separate task. 2) It is quite normal, that if something is blocking, you will want to create proxy like scenario - so main Rugby process listens to requests and chains them to another e.g. already pre-run Rugby processes, which will do the job. Once finished, your proxy will be noticed, and can transfer the result back to the user. 3) each request can wait for quite some time and even OS can help you (backlogging). The bad thing with Rebol is, that we can't influence tcp connection oppening/closure phase, which is still blocking, but it will change with Rebol 3.0, where we will get fully async protocols 4) Even Rugby has threads. If you write your function in clever way (but I expect it being rather difficult), you could accomplish concurrent calls to one function at "one time" 5) Rugy is blocking while writing to the port, but even this can be solved ... 6) Ppl should calm down sometimes :-) Do you want to run server being accessed by 10 ppl a sec, so generating 600 request per minute? 7) Have you ever tried Rugby? :-) Cheers, -pekr-

 [63/74] from: chris:langreiter at: 28-Apr-2002 3:01


> You haven't answered why you consider Rugby being blocking one ;-) I > tried Ruby several times and it does some 250 RPC echos in a sec ... So, > what is enough for you? :-)
I'm not talking about speed or Rugby's efficiency, which is certainly admirable, but there are things Rugby can't do anything about ... Rugby is blocking when executing long-running functions, like doing data analysis involving data gathering from multiple data sources (and many scenarios more). I've just had a look at the cooperative threading model, and it might be good enough for a lot of cases (though, in general, I don't like coop multithreading too much, it usually complexifies otherwise simple programs enormously).
> PS: what does your grin mean? Do you know something we don't? :-)
Unfortunately not. That's why I am asking here ... BTW, Roger Sessions may well talk a lot of nonsense, but his observation regarding SOAP I support. SOAP is (rather) complex when compared to XML-RPC or REBOL messaging. It is probably extremely simple simple when compared to CORBA. And he who deems "XML" simple hasn't seen it in its full glory. -- Chris

 [64/74] from: gchiu:compkarori at: 29-Apr-2002 12:31


On Sun, 28 Apr 2002 10:45:34 -0400 "Cybarite" <[cybarite--sympatico--ca]> wrote:
> Sounds like violent agreement ... if you ask me... which > no one did. > If SOAP becomes ubiquitous, REBOL needs to be able to > interoperate with it.
I think the real question is the one DocKimbel raised.
>i would like to know if RT has plans to implement an >enhanced >XML parser/builder at mezzanine or native level ??? If >not, my first task would be >to make a complete and optimized one. (Maybe starting >from
Gavin's work)
>So, anyone from RT here to give us infos on what they're >cooking for XML ?
Once that is done, everything else falls into place. -- Graham Chiu

 [65/74] from: chris:langreiter at: 30-Apr-2002 15:23


> No, it isn't Rugby's fault, sorry :-) Your scenario is of course > correct, but replace Rugby and Rebol by Java, etc. - it's just the same. > If some func takes 10 sec, then it takes 10 sec. Maybe using Java, it > will be faster, but still blocking.
Petr! NO!!! That's the point! As Java has some wondrous feature set collectively named "multithreading", you can write non-blocking servers quite easily ...
> 1) I know where you are trying to point maybe - is that threading? Well, > you don't need threading to help solve it - you can launch separate task.
Yes, you could write a "broker" which does nothing but shuffle data from and to "worker" processes, but that won't help you much when the data transfer process itself is blocking (i.e. when receiving a 10MB file from a client).
> 5) Rugy is blocking while writing to the port, but even this can be > solved ...
How so?
> 6) Ppl should calm down sometimes :-) Do you want to run server being > accessed by 10 ppl a sec, so generating 600 request per minute?
There are lots of scenarios where I'd like to use REBOL as an in-memory data engine and where one web request (e.g.) could easily result in about 50 queries to that data "server", some of which might well take some time to complete. So it's absolutely realistic and there's nothing to "calm down".
> 7) Have you ever tried Rugby? :-)
Yes. Indeed I have written a simple file-sync utility with Rugby (not unlike Novell's iFolder, but without all the features ;-). It started to eat up memory after awhile and I never came around to really debug it ... Bye, -- Chris -- Best regards, Christian mailto:[chris--langreiter--com]

 [66/74] from: mla:itinko at: 30-Apr-2002 9:50


Just to clarify, Java server side implementations (Servlet) usually assign one thread for each connection (plus any necessary additional threads for asynch processing). So in the given example carla would not be blocked while peter's request is being processed. Also note that forking an additional process is much more expensive resource wise (and slower) than forking a thread. That's why Java servlets are much more efficient than CGI/ASP (although ASP.NET resolves this with threads and compiled pages - aspx). Just had to jump in here, being a Java advocate and all. Rebol 3.0 sounds cool! Michael

 [67/74] from: petr:krenzelok:trz:cz at: 30-Apr-2002 19:25


Christian Langreiter wrote:
>>No, it isn't Rugby's fault, sorry :-) Your scenario is of course >>correct, but replace Rugby and Rebol by Java, etc. - it's just the same.
<<quoted lines omitted: 5>>
>collectively named "multithreading", you can write non-blocking >servers quite easily ...
so you say - you "can write" ... and I mean ... you can spawn tasks using Rebol .... in another reply someone argued that starting new task is much more expensive. But - e.g. Apache itself uses tasks - not threads, at least Apache 1.x family. I also heard that under Unix, starting new task is not as much expensive as it is under Windows. I know that stuff you are asking for does not exist, but you "can write" it in Rebol too ... see below ...
>>1) I know where you are trying to point maybe - is that threading? Well, >>you don't need threading to help solve it - you can launch separate task.
<<quoted lines omitted: 4>>
>data transfer process itself is blocking (i.e. when receiving a 10MB >file from a client).
Well, then your demands are really high ...
>>5) Rugy is blocking while writing to the port, but even this can be >>solved ... >> >> > >How so? >
I think that Maarten has showed some example? I don't remember correctly though. Of course streamed read/write would be cool, but we don't have it yet. But imagine higher level function, e.g. accept-file, and client side one - send-file. You can can just create it in higher level. Client can set-up deferred connection, first announce server the size of file being transferred, and you can even set-up custom protocol, e.g. first byte having some meaning - e.g. discard transfer, etc. You can open port to file on the client side, and open port to file on the server part, so it will be even memory savy. I don't know how difficutl it would be, but both sides could instlall green threads, to process transfer in the background ...
>>6) Ppl should calm down sometimes :-) Do you want to run server being >>accessed by 10 ppl a sec, so generating 600 request per minute?
<<quoted lines omitted: 5>>
>well take some time to complete. So it's absolutely realistic and >there's nothing to "calm down".
I really mean it :-) Just replace REBOL above with the word Apache. It listens on 80 port and serves many clients, not using threading, but tasks, which can be pre-started. You could also program some basic load-balancing for Rugby ... Of course I would be glad too, if we had fully async stuff already, and some kind of similar framework would exist .... But I think that community even haven't pushed Rugby to its limits ... But I am occassional Rugby tester - it would be maybe good to let's Maarten to comment ... :-)
>>7) Have you ever tried Rugby? :-) >>
<<quoted lines omitted: 3>>
>to eat up memory after awhile and I never came around to really debug >it ...
... yes, it was happening to me too, at least with some earlier versions. My Apache fast-cgi process went to some 80% usage and was eating resources up. Maybe it was not Rebol/Rugby's fault ... who knows ... Cheers, -pekr-

 [68/74] from: greggirwin:mindspring at: 30-Apr-2002 9:29


hi Chris, << though, in general, I don't like coop multithreading too much, it usually complexifies otherwise simple programs enormously >> Compared to no threading at all, or compared to pre-emptive multi-threading? I think it can be more work to set them up, but they tend to me more robust because a) you have to think about how threading is going to affect your app, b) they're far easier to debug should things go awry, and c) they can help you avoid deadlocks and race conditions because you don't have critical sections to deal with as you would in a pre-emptive system. I'm not a Java guy, so I can't speak to its multi-threading design and how it make hinder or help. --Gregg

 [69/74] from: mla:itinko at: 1-May-2002 0:41


I have met complex women and seen glorious sunsets! I admit I have yet to run into one complex XML document "in its full glory". Please, someone enlighten me, what am I missing here :-? Michael

 [70/74] from: maarten:koopmans:surfnet:nl at: 1-May-2002 11:01


Gregg Irwin wrote:
>hi Chris, ><< though, in general, I don't like coop multithreading too much, it usually
<<quoted lines omitted: 5>>
>help you avoid deadlocks and race conditions because you don't have critical >sections to deal with as you would in a pre-emptive system.
I second this. I had to implement this and then use it for the first time ;-) It is good to be forced to think about your code in all possible ways. Most of the time (IMHO) if you can't get it done with coop multithreading, you surely are not up to doing it preemptive. You just don't see your race conditions...
>I'm not a Java guy, so I can't speak to its multi-threading design and how >it make hinder or help. >
Java added non-blocking I./O in 1.4 to facilitate writing high-performance network services. Because it is an easier programming model etc. ;-) --Maarten

 [71/74] from: gavin_mckenzie:fastmail:fm at: 1-May-2002 11:06


Michael, Hopefully we'll hear from Christian on what he meant...but I couldn't resist jumping in. IMO, whether XML is simple or complex is a matter of perspective. A classic half-full, or half-empty scenario. But, some people probably also think that the contents of the glass have long exceeded the limits of surface tension and are spilling out onto the floor. XML itself is wonderfully simple. That is, the XML 1.0 Recommendation is simple. You can create your own wee grammars / markup-languages with it without breaking a sweat. If you are a person tasked with designing a set of interoperable data/message formats within a closed-system that you control, then you can adopt XML easily and quickly. Of course, given that you live in a happy world of a closed system where you own the data flows, it might also be tempting (or considered the 'one true way' by people on this list) to say "pshaw!" to XML and use a REBOL-centric approach for designing your data/message formats instead. If, on the other hand, you are someone who has to build your software in such a way that it can interoperate with other people's software (that you have no control over) then XML can be a blessing; but, XML won't seem so simple anymore. This is because what makes XML 'not so simple' in this scenario is that it has a bunch of friends and neighbours called: - XML Namespaces - XML Schema and/or DTD - XSLT, XPath - XML-DOM - the list goes on... The associated technologies build on the original XML 1.0 and extend XML in various directions. Many of those technologies are vitally important to being able to interoperate with someone else's system that claims to speak "XML" or to create compound/hybrid data formats or message types. So, XML really is simple. You can learn most of "XML" in a couple of hours. Becoming an expert takes a *looong* time. The devil is in the details. For some, the details in XML do more than introduce you to the devil; they drop you in the seventh level of hell! Whether this matters to you is, again, a matter of perspective. What problem are you trying to solve? How much XML do you need? Gavin. P.S. My desires for REBOL to have a more robust foundation for XML processing are because I believe that REBOL *is* a horizontally positioned technology. REBOL, IMHO, is supposed to help me create 'glue' that binds applications together. Therefore, I desire all that extra XML "stuff" in REBOL beyond just simple XML. On Wed, 1 May 2002 00:41:18 -0400, "Michael Appelmans" <[mla--itinko--com]> said:
> I have met complex women and seen glorious sunsets! I admit I have yet > to run into one complex XML document "in its full glory". Please, > someone enlighten me, what am I missing here :-? > > Michael >
-- Gavin McKenzie http://www3.sympatico.ca/gavin.mckenzie [gavin_mckenzie--fastmail--fm] http://fastmail.fm

 [72/74] from: greggirwin:mindspring at: 1-May-2002 9:38


Excellent post Gavin. Very well said. --Gregg

 [73/74] from: greggirwin:mindspring at: 1-May-2002 9:43


<< Most of the time (IMHO) if you can't get it done with coop multithreading, you surely are not up to doing it preemptive. You just don't see your race conditions...>> Yes indeed. Just as "creeping featuritis" is bad for deadlines, "semaphore population growth" is bad for maintenance and reliability. :) --Gregg

 [74/74] from: mla:itinko at: 1-May-2002 12:47


Gavin... I agree with you, that it's really a matter of perception. And to clarify I consider XML just that, the W3C 10/6/2000 XML 1.0 (second edition)recommendation (and perhaps XML Namespaces 01/14/1999). When I talk about XML or SOAP I'm not speaking of the plethora of ancillary technologies like XSLT (which can be quite complex), XPATH, JDOM etc. I think the fundamental question is Rebol going to have an XSLT engine available? This would probably be the most difficult aspect of supporting XML processing in Rebol. That and XMLQuery! If Rebol is to coexist with heterogenous systems then fullfledged XML (and SOAP) support is mandatory. Even if it is complex, unwieldy or even ugly ;) Michael

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted