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

SDK FAQ? Re: Re: time to read

 [1/6] from: petr::krenzelok::trz::cz at: 3-Dec-2002 11:20


Gregg Irwin wrote:
>Hi rishi, > >r> http://www.rebol.com/docs/sdk/index.html > >Woo hoo!!! > >-- Gregg >
Except the woo-hoo, wow etc., there is plenty of questions arising though :-) Maybe some of them could become part of SDK FAQ? - unset-reg-funcs could be none by default ... but not a big problem to have it included all the time ... (this one is for us, registry haters and does not necessarily needs to be answered :-) now to products: - what is the future of /View, /Core and /Command products in regards to SDK aproach? Will they further exist? - does SDK license allows us to install /Base + some additional scripts (sources) taken from SDK into web-server space e.g.? I don't see it reliable to build encapped app for every cgi script I may wish to put into webserver, while /Base provides us with faster booting, lower memory requirements, etc.? Stating that - will /Base, /Face and /Pro exist as separate products, or only for encapped-app purposes in terms of SDK? - docs say that /Pro is built upon /Base, including some of current /View/Pro and /Command features (shell, library, fastcgi), but /Face itself does not contain network protocols. If /Pro is supposed to be used mainly in conjunction with CGI, how is it supposed to work without network protocols? Or is the SDK strategy suggesting to Encap particular CGI scripts rather than use Rebol interpreter to run non-encapped ones? - can we regard /Face being a superset of /Base + /Pro, and compare it to current /View/Command product? (except the differences of /Face and /View, as VID and some mezzanine functions)? - SKD docs say: "To run /Face, your SDK license.key file must be provided. This is the same license.key file that is required to run the encapsulation program and should not be distributed ..." - will there be /Face product, not containing /Pro features, which can be distributed withouth user license key, or just opposite - how are we supposed to create end-user license keys? Is the procedure to ask RT for them? Thanks, -pekr-

 [2/6] from: greggirwin:mindspring at: 3-Dec-2002 11:07


Hi Petr, I was thinking that maybe a good way to lay out its purpose would be to have sections targeted at various uses for the SDK. E.g. === If you're a commercial/shareware developer The SDK allows you to... === If you develop in-house tools, or are a system administrator You can use the SDK to... === If you're writing CGI scripts with REBOL === If you just use REBOL for fun, but want some of the features found in the SDK etc. PK> If /Pro is supposed to be used mainly in conjunction with CGI, how PK> is it supposed to work without network protocols? Do you need net protocols if you're just generating pages? It would be used in some that read data from other sites, of course, but then you just load the one(s) you need. I think boot time is the big thing they want to address. Our encapped app today loads faster than non-encapped, so I'm guessing an encapped /Base app will be great for CGI. You've got some good questions in there Pekr. -- Gregg

 [3/6] from: rotenca:telvia:it at: 3-Dec-2002 20:22


Hi Gregg Irwin
> Our encapped app today loads faster than > non-encapped, so I'm guessing an encapped /Base app will be great for > CGI.
This problem was adressed by Arexx with a great solution 20 years ago: a process was waiting on a port for string to execute or file name to read and execute. You can send message to this port from an Arexx script or with a very little executable program from the shell (little because it only read parameters and sends a message to the message port). And more: the Arexx script can be executed sync or async, with a result value or without (and other options). Encap is not a solution for this problem. --- Ciao Romano

 [4/6] from: greggirwin:mindspring at: 3-Dec-2002 13:13


Hi Romano, RPT> This problem was adressed by Arexx with a great solution 20 years ago: a RPT> process was waiting on a port for string to execute or file name to read and RPT> execute. You can send message to this port from an Arexx script or with a very RPT> little executable program from the shell (little because it only read RPT> parameters and sends a message to the message port). RPT> And more: the Arexx script can be executed sync or async, with a result value RPT> or without (and other options). RPT> Encap is not a solution for this problem. Agreed, but it's an improvement. FastCGI and LRWP are meant to address that as well, right? If you write your own web server in REBOL, you can do anything you want though. :) I think another advantage for /Base, etc. in a CGI context is the smaller memory footprint. -- Gregg

 [5/6] from: gchiu:compkarori at: 4-Dec-2002 11:45


----- Original Message ----- From: "Romano Paolo Tenca" <[rotenca--telvia--it]>
> This problem was adressed by Arexx with a great solution 20 years ago: a > process was waiting on a port for string to execute or file name to read
and Trouble is, most ISPs will not allow you to run a persistent process like this. --Graham http://www.compkarori.com/cerebrus/index.html This hound hunts down spam!

 [6/6] from: lennart:nylen:biz at: 4-Dec-2002 9:52


2002-12-03 20:22:23, "Romano Paolo Tenca" <[rotenca--telvia--it]> wrote:
>This problem was adressed by Arexx with a great solution 20 years
ago: Erhm, surely ARexx didn't exist 20 years ago. AFAIK it was bundled with AmigaOS 2.0 and up. Since the 'A' in 'ARexx' stands for 'Amiga, it can't be more than, say 15-17 years, can it? Just nitpicking, please ignore me. :-) /Lennart Fridén ([lennart--nylen--biz]) The World is not sane so why should I be?