I think that callback support can easily be integrated into the existing
callback APIs.  Here is an example of an API that supports both blocking
and non-blocking syntax.  If you leave out the callback and are in a
coroutine, it will suspend the coroutine while blocking on the I/O.  The
internal code can still do things in parallel with callbacks, but the
external API is nice and sync.

https://github.com/luvit/luvit/blob/c83252fcf2b085fb9c272425b008a829fe6879ec/test-tls.lua#L276-L299

The helper code to make this possible wasn't very hard.

https://github.com/luvit/luvit/blob/c83252fcf2b085fb9c272425b008a829fe6879ec/test-tls.lua#L19-L45

Integration with a callback API simply requires a new line at the top at
the bottom and callback internally replaced with `next`.

https://github.com/luvit/luvit/blob/c83252fcf2b085fb9c272425b008a829fe6879ec/test-tls.lua#L50-L71

What do you think?  Should luvit 2.0 keep all the existing APIs, but also
add this where possible?

On Fri, Oct 24, 2014 at 4:02 PM, Chris Hoffman <[email protected]> wrote:

> Yeah.
>
> The majority of the application uses features from
> http://wiki.nginx.org/HttpLuaModule but we also use
> http://leafo.net/lapis/ to wrap some of the common web service tasks and
> do a more Rails style deveopment. Ideally I want to get to a point of a Lua
> based connect (from node.js) environment with a middleware oriented
> community.
>
> We've found Lua using LuaJIT is a surprisingly capable high level
> language for embedded systems development.
>
>
> On Friday, October 24, 2014, Tim Caswell <[email protected]> wrote:
>
>> Thanks Chris, do you have a link for the nGinx API you want feature
>> parity with?
>>
>> On Fri, Oct 24, 2014 at 3:36 PM, Chris Hoffman <[email protected]>
>> wrote:
>>
>>> Agreed. The event emitter API is powerful. Using co-routines to thier
>>> potential could make that interface very drool worthy. One thing I
>>> personally would like to see is a parity with the NGinx lua API. I started
>>> a project a while ago with that because the future of luvit seemed
>>> uncertain at the time. I would love to migrate to pure luvit.
>>>
>>>
>>> On Thursday, October 23, 2014, Wouter Scherphof <
>>> [email protected]> wrote:
>>>
>>>> I like the event emitter api. Doesn't have to be callbacks.
>>>> Putting coroutines to proper use would be awesome.
>>>> For package management, use npm. Because you can. Presently.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "luvit" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "luvit" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "luvit" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "luvit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to