I'm writing my own awake handler for this, I just don't know how should to deal with his situation :)
hmm, not sure what is the problem...you should be able to handle that situation using the READ/WROTE events, no?
So should there be some loop in READ event?
something like until some-mysterious-condition [copy port/data] ?
I think first you need to know how much you read already, how much is left to read, if you are at the end of the response or not etc. and build logic around that in the awake handler. What protocol are you trying implement?
Also look at the examples...I don't remeber it from my head directly but you can either read or write on the port from the READ event depending if you want to wait for more data or send something to the server etc. It all depends on the protocol definiton.
Rebolek, IIRC you just call READ again on the port if you want to read more in the 'read event. That will trigger a new 'read event once new data is ready. You should check existing examples (eg. HTTP), I don't know what the state of the documentation is.
this will trigger a new 'read event where you call COPY again etc.
This is from memory so I might be wrong.
For example, in the HTTP scheme, in the 'read event I call the check-response function, which determines if more data is needed (do we have all the headers? do we need content data? etc.) and calls READ on the port accordingly.
actually, I think that returning TRUE from the 'read event means "we are done, no more data to read", which signals the higher level READ to return your data. But, I might be wrong here, I don't remember the details.
Ah, OK, so calling READ from READ. I will try that. Thanks.
Yes, I think Gabriele is right...you need to call READ action from READ event. AFAIK you can also WRITE on port from READ event to send some data to server if necessary...etc. It depends on the protocol spec/logic you need to follow.
>> load ftp://user:email@example.com/ ** Script error: cannot access state in path port/state/connection ** Where: read either read-decode case load ** Near: read source if find system/options/file-types type [data: de...
I was wondering if this is a known issue or a regression?
The same port/state/connection error shows up when trying to write a file as well.
Then I don't know because it works for me and others
Try to put R3 in a different folder and try again.
Or maybe your prot-ftp file has been modify in some way?
Isn't 3.0 the Atronix version?
2.101 is the official or community version
Yes, Atronix version ... but everyone else is using different versions and it works
Well, Alan's version is not ancient
The times I have seen this _not bound to a context_ error is I think when something has not been defined as a local in module before it is then used. Alan's first version he was using was from Aug 2013 which is pretty old is it not?
Hardly ancient I would say
Do you have any suggestions as to why he is getting this error?
I re downloaded prot-ftp and it now works...I do not remember where I first downloaded from but it was not from git hub ...may have a bad version out there somewhere...
GrahamC: Using FTP with R3 is on my list of projects, but I haven't actually had a chance to work on it. Been too busy with the several dozen other projects I'm involved in right now. :-\
Someone works with FTP on Android ?
The same program run in Windows but no in Android. No errors only get
port opened ....
@amacleod .. the error you saw was a result of a change in modulel handling and the version on github was supposed to correct it. So, likely you just had an old version around.
@Luis .. I've not tried ftp on Android. Do the other protocols works?
Not sure if this it the case but in current R3 you have to wait on the port that operates on the real connection (usually tcp scheme). If you wait on the 'topmost' port used by some higher-level scheme the real 'connection port' will be awaken but not the 'topmost' one. To solve this annoyance, we probably need to introduce new field to the port object (like port/parent-port) using which the AWAKE handler can find the top-most port easily and resolve correctly waiting on higher-level scheme wrappers.
I'd like to use the term socket to indicate the real tcp-level port to ease the terminology confusion here. And yes, the ftp protocol does do a wait on the socket. It works fine in other OS, just not Android according to Luis' tests.
@Luis .. I think the issues you were having with ftp protocol on Android are related to the alpha event handling on Android.
Cyphre could confirm.
Graham, it could be...Luis, if you have any simple test script (preferably using some free test ftp account so I don't need to create one) I could quickly try here to see what's goign on.
so that I return the headers and body. Any thoughts on this?
Obviously the main idea is to be able to grab the cookies.
If people think this is worthwhile, I'll make a PR on one of the Rebol3 repos that is being actively maintained
I think its a good idea (actually, almost essential in today's web environment) .
when doing a successive read, there should also be a transparent way to modify and re-submit the same cookies... say, by adding a cookies attribute to the http port and maybe a few functions for modifying them (add, redate, update)
Luis, thanks...will give it a try hopefully soon.
@Maxim, I can't see how you'd do this using successive reads since the http protocol doesn't preserve state. and currently if you open a port, you lose access to the write dialect.
Thanks for the suggestion, Josh! I downloaded Graham's prot-spop3.reb and Gabriele's fsm.r (which I renamed fsm2.r as I couldn't find an fsm2.r - it seemed to work without error). It appears to be able to open two different POP3 mailboxes, but both of them show 0 messages even though I know they both have messages in them.
I guess you'll have to check with Graham. I believe he has said his protocols were completed
It looks like part of the problem I'm having with spop3 is that it doesn't throw up an error when there is no mail server on the other end, or if the settings are incorrect.
OK. So there is a bug with the ARM version of R3. I tried the Atronix latest branch and a version from 2013. Both had the same problem. Both always show that there are no messages in the mailbox when using any version of pop, spop, or imap. The exact same script with the exact same credentials on a version of R3 from Feb 2014 works fine on Windows.
Has anyone ever tried to re-activate / port Rebol Services to R3?
I liked it a lot but lost track about its state and which problems and things are still open.
R3 chat is based on a successor
So the design is still in limbo and the code missing in action
I use 0MQ instead
Is the R3 chat service stuff published and documented a bit?
R3 Chat is imo in no way a successor. When I talked to Carl, he wanted to rewrite Rebol/Services to eventuallly simplify some concepts, etc.
Yes, and he did that in R3 Chat. He said the interface collapsed in such a way that he didn't think tthe REBOL/Services concept was needed anymore
The chat client code is available because it is downloaded, but as far as I know, the server was never published
Carl's ideas were all in flux, so there is no documentation, either
I know it was ask to him several times, but it would be cool to ask again : "please, can you give us the server code !"
Like Kaj, I've decided 0MQ is a better way to go at this point.
Taking on this, I'm a bit fan on the BEEP protocol building framework. It offers some higher level features thatn 0MQ.
I always thought it's a very cool (maybe even a killer feature) to build such an application protocol framework right into R3. So, when you want to do P2P, Client/Server etc. and use R3 on both ends, you just use this BEEP stuff and all networking problems are gone.
I'm still convinced that it makes a lot of sense.
That was also kind of idea of Uniserve, upon which Cheyenne is built. Maybe a bit inspired in Python's Medusa. All protocols are hot plugs IIRC. I too think, that some kind of general mechanism, upon which various (app) protocols could be built, would be fine. In that regards, I found R3 Chat being a step back, not forward ...
And I wouldn't do all the low-level stuff in Rebol but on the C side.
Didin't Ladislav write BEER a long time ago?
Yes, in Rebol. With a lot of problems.
I don't know if it was standard conform or just a fork of the idea.
I don't either. Probably have an old copy somewhere here. Lad's stuff has been offline for a while I think.
I think I liked the idea of a way to build protocols like PARSE lets us build DSLs, but never got it to stick for me.
I would not try to overcome port mechanism, whatever it takes. If there are bugs, those should be fixed. Well, it might be an extension (which is C). We will see, how Red IO turns out, once out ...
I don't like to port model that much. Might be because I never digged deep enough into it. But trying to generalize IO with a common API or model was tried in several other enviironments and all I know failed.
IMO putting network stuff to a higher level makes sense. Much higher level so that I can think of it in sending things back and forther and that's it.
Have you looked at 0MQ? It's basically send/receive, with socket types that have semantics (req/rep, pub/sub, push/pull).
0MQ looks like that on the surface and in the marketing, but when you start making real systems, you have to do a fair bit more
The problem with those network abstractions is that there quickly are reasons you have to poke under the hood
Have you found something better? It's all about tradeoffs, right?
Now I'm tickled
Kaj, maybe I should ask, instead, what poking under the hood you've had to do. I'm not stressing 0MQ in my work (very low message rates, largely for IPC), but some other work I did with it a few years ago hit it much harder and was still very easy to do.
Most simple examples, and what most people start with, is request/reply, but this quickly becomes useless in real-world situations
To be more flexible and scale it, you have to switch to dealer/router, which means managing and interpreting the multiple parts of request/reply messages, including the under-the-hood identity part
Now you're juggling sub-messages and babysitting their consistency, and soon you have to manage the internal sub-messages by creating, copying and destroying them, and comparing their content
First you think, ZeroMQ is about queueing, so I don't have to make my own message queues anymore, but again that only works in the simplest examples
When you need more flexibility and performance, you're back to maintaining your own message queues, and the 0MQ queues become a hindrance, because you can't access them once a message is in there
I'm probably spoiled because I never worked with earlier, complex messaging systems, but this is my experience
It would also be different if you're working with low-level languages, but in REBOL/Red a message queue is easy to do, so why give up control over it?
Kaj - having your experience with ZeroMQ - what do you think about the Rebol/Services architecture? Is it any better in organising more higher (app) level stuff, than starting with low level ZeroMQ stuff?
I see BEEP at a much higher level than 0MQ. It's for application developers, you care about the application protocol not the technology below. Here is an even higher-level lib build on top of BEEP: https://www.tml-software.com/
Petr, I just happened to review REBOL/Services again with the hindsight of 0MQ experience
It's amazing how Carl solved all the same problems at around the same time 0MQ was designed
Also, a lot of stuff that was traditionally missing from 0MQ is in R/S, such as encryption and authentication
On the other hand, both fail to provide the first needs most people have: an HTTP transport that is able to traverse firewalls is missing from both
Further, R/S manages to cripple its added value of encryption by only providing cloaking in the free version, and requiring paid versions for real encryption that you can't even order anymore
R/S is much nicer and quicker to program because it's all REBOL, but 0MQ's point is the reverse: that it's language neutral, which is also very powerful
They target two entirely different problems. Hard to compare them. And R/S does have the CGI option.
I see a big overlap between them
LNS (R/S) is high-level dialected req-rep (not always RPC) over, theoretcially, any transport and is point-to-point client-server. 0MQ is mid-level sockets with semantics. Mid-level meaning framed messages, multiple connection points, brokering/proxying, buffering, etc. LNS also has the concept of an admin interface and file sharing, but those are incomplete AFAIK.
I like both, but they are very different to me. I LOVE the idea of a completely native REBOL solution, but 0MQ opens the door to interacting with other systems.
And we should be able to use 0MQ as just another transport for LNS, right?
Yes, 0MQ is leaning towards transports, while R/S is leaning towards defining message formats. In the middle, they overlap
Looking at R/S in terms of 0MQ, it's not completely clear what R/S offers, but it looks like it's more like 0MQ dealer/router than request/reply
0MQ's flexible other topologies are not offered by R/S, so it's a matter of viewpoint which one would be considered more high level
When you need them in R/S, you'd have to implement them yourself on top of R/S's sort-of dealer/router
How do you see R/S as dealer-router?
It seems to be able to overlap multiple requests, which is essential for performance, and also means it needs to maintain internal message queues
However, it doesn't automatically generate node IDs like 0MQ, so it's less convenient in that
Ah, OK. And since there is no concept of distributing work, you would have to build all that yourself behind the server.