Async API (was: Async call:// protocol v1.0)

Hi Romano, You've raised a good point. I see the 'awake callback as a low-level hook in the event handling process. As you say, with 'awake you have to make your own internal state-driven dispatch code (usually calling helper funcs for bigger tasks). The approach I've used in call:// is just trying to simplify the work for the developer by hiding the low-level stuff (especially the dispatch code) and providing just the necessary hooks. These higher-level callbacks are easier to write (no required return value as in 'awake for ex.) and IMO make the code more easier to understand. I think that it's a little similar to View's feelings ('feel object methods): 'awake is equivalent to the 'detect func and higher callbacks are close to the code you would wrote in 'engage func. You usually rely on 'engage, because it's easier and faster to write, and use 'detect for writing special event handling routines in rare cases where it's necessary. If the higher-level async callbacks doesn't suit your needs, you're still free to use 'awake. I've found 'port/locals/on-my-func1 a little long to write and not very handy. Maybe this kind of functions should be located in a different 'port word. (port/call/...?) -DocKimbel. Romano Paolo Tenca wrote:

Hi Doc, I understand your point and i agree. I think that could be followed a path like the View one. i am thinking to the feel object, with recurring standard name until is possibile: My first attempt make me think to (arguments here are only example): port/locals/feel: make object! [ resolve: func ["dns lookup done" port][] read: func ["read op done" port][] write: func ["write op done" port][] end: func ["connection is closed by peer or task is at the end" port][] connect: func [ "connection is open" port][] detect: func ["low-level" port][] ] or port/locals: make object! [ .... (internal stuff) resolve: func ["dns lookup done" port][] read: func ["read op done" port][] write: func ["write op done" port][] end: func ["connection is closed by peer or task is at the end" port][] connect: func [ "connection is open" port][] detect: func ["low-level" port][] ] or it could be a block not an object. port/locals/feel: [] Not all functions are needed for all protocols, and sometimes they can have other meanings. In both cases, it should be a good thing to permit the user to define the function at make port! time. To reach this goal, a syntax could be: 1) p: open/custom url [resolve: [user-code ] read: [user-code]] or 2) p: open/custom url reduce [resolve: func [port data][user-code ] read: func [port data][user-code]] or 3) p: open/custom url [resolve: [port data][user-code ] read: [port data][user-code]] the last permits to define local vars without reducing the block: p: open/custom url [resolve: [port data /local a b c][user-code ]] perhaps all 3 cases could be supported by the handler with a parse rule. What do you think? --- Ciao Romano