Re: anything new?

> I tend to be partial to Tornado, because of the relative lack of 

> > features (yes, a virtue), and clarity of the code, but Flask, for 
> instance, 
> > would also work. 
>
> Huh? Flask is a web framework. 
>
 
A Web framework is also an RPC framework; it's just inefficient, with 
poorly defined semantics.

But many of the Web frameworks are also async frameworks -- you don't 
necessarily have to write a Web server with Tornado, for instance, you can 
just write a TCP server.  So you could write a ZEO server with Tornado the 
same way you write one with asyncore.  But Tornado would provide the 
abstraction layer around an implementation of async I/O.
 

> > Isn't the use of asyncio mainly on the server side to 
> > service requests from the clients? 
>
> ZEO clients talk to ZEO servers over a protocol that isn't HTTP, as 
> I'm sure you're aware. 
>
> I find using an async library attractive for implementing this 
> protocol on both the client and server, but the same library needn't 
> be used on both sides.


True enough.
 

> The existing client and server implementations 
> have lots of problems, on top of being implemented on an obsolete 
> async framework. 
>
> I'm committed to providing Python 2 support.


I figured as much.  So I'm not really worrying about this.
 

>  It's unclear whether 
> Trollius would be useful for this.  The main problems with Trollius 
> seem to be with the coroutine support, and the ZEO implementation I'm 
> working on doesn't use coroutines. 
>
> If Trollius isn't workable, then I'll have to use an abstraction to 
> make the networking library easier to change. Fortunately, I already 
> have one, zc.ngi, which I originally wrote to use with ZEO. I didn't 
> use it for this project because asyncio+Trollius seemed like they 
> would work.  I'm still a bit unconvinced that Trollius won't work.


My concern isn't that Trollius won't work; it's that Trollius is dead.
 

>  If 
> I have to, switching from asyncio to zc.ngi would be pretty 
> straightforward, as they're pretty similar. 
>
> For that matter, building a Python 2 implementation of the small parts 
> of asyncio that I'm using on top of some other async library probably 
> wouldn't be that difficult.


My concern is maintenance.  There are already a lot of moving parts here 
with what seems to be a small number of people supporting them.  It seems 
it would be a win to move those parts of the system which aren't directly 
about the object store to some other external framework with good support.  
If that external framework also brings in support for currently missing 
pieces (like encryption and authentication), all the better.

Bill
 

>
>
> Jim 
>
>
> > 
> > Bill 
> > 
> > 
> > On Tuesday, April 5, 2016 at 1:46:47 PM UTC-7, Bill Janssen wrote: 
> >> 
> >> Yes, this was the ref: 
> >> https://groups.google.com/forum/m/#!topic/python-tulip/mecVwhnVP0A 
> >> 
> >> Bill 
> >> 
> >> On Tuesday, April 5, 2016 at 1:45:27 PM UTC-7, Bill Janssen wrote: 
> >>> 
> >>> Didn't someone point out that Trollius is dead?  Maybe I should look 
> to 
> >>> see what Tornado uses under the covers... 
> >>> 
> >>> Bill 
> >>> 
> >>> On Tuesday, April 5, 2016 at 1:40:32 PM UTC-7, Jason Madden wrote: 
> >>>> 
> >>>> 
> >>>> > On Apr 5, 2016, at 15:34, Bill Janssen <[email protected]> 
> wrote: 
> >>>> > 
> >>>> > So perhaps I should fork the code and replace the asyncore code 
> with a 
> >>>> > Tornado-based ZEO server.  That way it would run on either 2 or 3, 
> and Ben 
> >>>> > Darnell could worry about the async parts. 
> >>>> > 
> >>>> > Bill 
> >>>> > 
> >>>> > On Tuesday, April 5, 2016 at 1:31:48 PM UTC-7, Bill Janssen wrote: 
> >>>> > OK, good to know.  Shame that's Python 3 only; I can't use that. 
> >>>> > 
> >>>> > Bill 
> >>>> 
> >>>> We're also still requiring Python 2 support. I have a 
> proof-of-concept 
> >>>> fork at https://github.com/NextThought/ZEO/tree/gevent that replaces 
> >>>> asyncore with gevent (which runs on 2 and 3), but I ran into two 
> problems: 
> >>>> 
> >>>> - I was trying to keep the overall design the same, and that turned 
> out 
> >>>> not to be a very suitable use of greenlets and gevent; in fact, it 
> performed 
> >>>> *faster* by simply having gevent monkey-patch select and threads in 
> place 
> >>>> than the native port I was working on. Some broader refactoring would 
> be 
> >>>> needed to best take advantage of gevent and greenlets and I didn't 
> have the 
> >>>> time then to look into it. 
> >>>> - gevent isn't really production strength on Windows in my opinion, 
> >>>> given the limits of libev and Windows select code, so that would be a 
> step 
> >>>> backwards. However, the gevent devs (me :) are looking into a port to 
> libuv, 
> >>>> which is production ready on Windows which would solve that 
> particular 
> >>>> problem. 
> >>>> 
> >>>> Jason 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "zodb" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to [email protected] <javascript:>. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Jim Fulton 
> http://jimfulton.info 
>

-- 
You received this message because you are subscribed to the Google Groups "zodb" 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.