Newbie needs help with Services

[1/14] from: kpeters-vu::ware::com at: 10-Nov-2005 15:30

Rebolers ~ I run a client & a server script both on the same XP machine in two instances of the current VIEW release: ;server script REBOL [Title: "Example Server"] do http://www.rebol.net/rebservices/server.r service: start-service tcp://:8000 ask "PRESS ENTER TO QUIT" stop-service service ;and the client script REBOL [TITLE: "Example client"] do http://www.rebol.net/rebservices/client.r result: do-service tcp://127.0.0.1:8000 [time] print result Whether I try localhost/127.0.0.1/real IP: The client just hangs and (after some timeout?) claims it cannot connect...??? Any help would be appreciated TIA, Kai

[2/14] from: gabriele::colellachiara::com at: 11-Nov-2005 12:37

Hi Kai, On Friday, November 11, 2005, 12:30:17 AM, you wrote: KP> REBOL [Title: "Example Server"] KP> do http://www.rebol.net/rebservices/server.r service: KP> start-service tcp://:8000 KP> ask "PRESS ENTER TO QUIT" KP> stop-service service You need to WAIT. do http://www.rebol.net/rebservices/server.r service: start-service tcp://:8000 wait [] ask "PRESS ENTER TO QUIT" stop-service service Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

[3/14] from: kpeters-vu::ware::com at: 11-Nov-2005 11:27

Thanks, Gabriele - things are beginning to work. Seems that the docs (http://www.rebol.net/rebservices/services-start.htm) need quite a bit of work: WAIT isn't mentioned anywhere and the server examples thus don't work. Also, with the WAIT in place, no one will ever see the ASK output from the server examples etc. [info title] requests worked for me - [time], however, did not: sever debug output: ------------------- DEBUG session: [valid-session? header-id 0 sess-id 2] DEBUG session: [sequence session-1 0 packet 1] DEBUG session: [reset-session 2] DEBUG request: [do-command [time]] DEBUG service: [dispatch home [time]] DEBUG error: [request-fail time] DEBUG packet: [header-out "REBSer 1 2 1 113 0"] DEBUG tcp: [send-packet 132] client output: -------------

>> do %/c/client.r

** User Error: command failed: time bad-command ** Near: do make error! msg

Any ideas as to why ? TIA, Kai

[4/14] from: gabriele::colellachiara::com at: 11-Nov-2005 21:35

Hi Kai, On Friday, November 11, 2005, 8:27:31 PM, you wrote: KP> Seems that the docs KP> (http://www.rebol.net/rebservices/services-start.htm) need quite a bit KP> of work: KP> WAIT isn't mentioned anywhere and the server examples thus don't work. KP> Also, with the WAIT in place, no one will ever see the ASK output from KP> the server examples etc. The ASK was enough on the /ASYNC version of REBOL/Core, because everything is async there, console included. But that does not work in View 1.3 and you need to explicitly WAIT (or DO-EVENTS). KP> [info title] requests worked for me - [time], however, did not: Indeed - DATE is the correct command. You can use the COMMANDS command to get a list (only in the HOME service right now, but that will hopefully work for any service in the future). Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

[5/14] from: kpeters-vu::ware::com at: 11-Nov-2005 19:18

Thanks again, Gabriele. The next thing I tried was: getfile: do-service tcp://localhost:8000 [file/get %/c/client.r] which fails like this: DEBUG session: [reset-session 39] DEBUG request: [do-command [file/get %/c/client.r]] DEBUG service: [dispatch file [get %/c/client.r]] DEBUG error: [request-fail file/get] DEBUG packet: [header-out "REBSer 1 39 1 126 0"] DEBUG tcp: [send-packet 146] getfile: do-service tcp://localhost:8000 [file/get %/c/client.r] } ** User Error: command failed: file/get no-file /c/client.r ** Near: do make error! msg

Any ideas as to why? TIA, Kai

[6/14] from: gabriele::colellachiara::com at: 12-Nov-2005 12:20

Hi Kai, On Saturday, November 12, 2005, 4:18:40 AM, you wrote: KP> getfile: do-service tcp://localhost:8000 [file/get %/c/client.r] KP> } KP> ** User Error: command failed: file/get no-file /c/client.r KP> ** Near: do make error! msg

>>>

KP> Any ideas as to why? The file service is not giving access to the whole filesystem. By default, it will only give access to %/path-to-server/public/ . The file service is definitely going to be improved in the future. Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

[7/14] from: kpeters-vu:ware at: 12-Nov-2005 13:05

Thanks Gabriele ~ I guess it makes good sense to only allow access to a certain directory by default. The final question for today then is: Why did my client run into an exception instead of returning a clean service result of type "fail" as the documentation says it would? TIA again, Kai

[8/14] from: gabriele::colellachiara::com at: 12-Nov-2005 22:46

[9/14] from: kpeters-vu::ware::com at: 15-Nov-2005 11:58

Hi Kai, On Saturday, November 12, 2005, 10:05:00 PM, you wrote: KP> Why did my client run into an exception instead of returning a clean KP> service result of type "fail" as the documentation says it would? Because WAIT-SERVICE throws an error when it gets a "fail" result. (Actually, anything except 'done.) Regards, Gabriele. -- Thanks again, Gabriele ~ so as it stands, this is not half as usable then as the documentation had me believe... Naturally, I'd like it to work as described in the outdated documentation, with clean failure indicator(s) in the service result and not throwing errors at the client side. Are there any plans to change that behavior? Any way to circumvent this for the time being? Thanks, Kai

[10/14] from: volker:nitsch:gmai:l at: 15-Nov-2005 21:09

On 11/15/05, Kai Peters <kpeters-vu-ware.com> wrote:

> Hi Kai, > On Saturday, November 12, 2005, 10:05:00 PM, you wrote:

<<quoted lines omitted: 19>>

> To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.

Why? if i dont miss something, thats like missing files, bad data format etc is handled too? it throws an error, and if you dont like it, use attempt[read something] -- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

[11/14] from: kpeters-vu:ware at: 15-Nov-2005 14:34

Volker ~ I guess we have to agree to disagree then: For instance, your 'attempt solution' fails at multiple results for multiple service requests ... [ ok [time 25-Mar-2005/12:08:12-8:00] ok [info "Default REBOL Service"] fail [file/put not-allowed] fail [file/get not-exists] ] And no, I don't believe the fix is to break the code above down into 4 single requests and wrap them in attempts. Besides, to me it's just plain wrong - or would you accept a SQL client library that coughed every time it received an empty result set from the server? These things are not what I would consider errors to be thrown - they are plain expectable results. My 0.02 Kai -- Why? if i dont miss something, thats like missing files, bad data format etc is handled too? it throws an error, and if you dont like it, use attempt[read something] -- -Volker

[12/14] from: volker::nitsch::gmail::com at: 16-Nov-2005 9:31

On 11/15/05, Kai Peters <kpeters-vu-ware.com> wrote:

> Volker ~ > I guess we have to agree to disagree then:

<<quoted lines omitted: 8>>

> And no, I don't believe the fix is to break the code > above down into 4 single requests and wrap them in attempts.

agreed. thought errors happen only with a single request, as mentioned in the docu. with multiple results i like an error too, but each response should be available. But how to return both? global is ugly.

> Besides, to me it's just plain wrong - or would you accept a > SQL client library that coughed every time it received an empty > result set from the server?

I dont like lazy errors where something goes wrong, is not handled and plays domino-errors later. an empty result-set in sql is no error. a missing file is. a sql-rebservice should return an empty block then. errors are easily catched. easier than checking a result actually.

> These things are not what I would consider > errors to be thrown - they are plain expectable results.

<<quoted lines omitted: 9>>

> To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.

-- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

[13/14] from: gabriele:colellachiara at: 16-Nov-2005 12:09

Hi Kai, On Tuesday, November 15, 2005, 8:58:51 PM, you wrote: KP> Naturally, I'd like it to work as described in the outdated KP> documentation, with clean KP> failure indicator(s) in the service result and not throwing errors at KP> the client side. Use SEND-SERVICE then. DO-SERVICE is meant to simplify usage, that's why WAIT-SERVICE throws an error. (You can use exceptions instead of having to check the result.) Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

[14/14] from: gabriele::colellachiara::com at: 16-Nov-2005 12:08

Notes

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