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:yah:oo 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::yahoo 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