I think that my next big project might be to
refactor ZEO's networking architecture.

Wonder what the main reason is?

- Provide more secure connections? Nope
- Leverage Twisted? Nope
- Get rid if the insane async/sync client madness? Nope
- Get better storage-server performance? Nope
- Allow simultaneous syncronous calls from the same client? Nope

I'd like to do all of these things, but the main reason to refactor
ZEO's networking architecture is to make it testable.

Writing ZEO tests now requires actually starting servers and
clients.  This is nuts.  IMO, application code shouldn't
touch sockets.  Application code, like ZODB and ZEO should
be insulated from actual network APIs.  They use simpler APIs
that are easy to interccept and control.

I've been thinking of a someone general networking API with these aims
in mind, but I realized that the ZEO existing frameworks could probably
be refactored in a more limited way to do this.  We'll see.

If anyone is interested in workingon this with me, let me know.

Jim

--
Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to