[sldev] Fresh new code: eventlet and mulib

Ryan Williams rdw at lindenlab.com
Fri Aug 24 17:25:40 PDT 2007


We've opened the source to two of our internal web services libraries 
today.  As you know, Linden is in the process of moving our 
infrastructure over to web services, to improve scalability, 
reliability, and interoperability.

A major aspect of this move has been to make it easy to write and use 
scalable web services, and eventlet and mulib have totally helped us 
with this goal.  The credit for these libraries belongs to Donovan 
Preston and Bob Ippolito, who wrote Eventlet together a while ago.  
Donovan brought Eventlet to Linden and added Mulib on top of it, and 
life was rad.

These two libraries are relatively disentangled from the rest of our 
codebase, and they're also generically useful for 
non-Second-Life-related projects, so we're going to treat them as such.  
We're going to use public repository as the source of truth, and do all 
our development there.  We have a branch about to enter QA that has the 
public repositories svn:externals'd in, that's how serious we are about 
this.

Both eventlet and mulib are licensed under a MIT license, because we'd 
like to encourage the widest possible use.

Here are the urls of interest:
http://wiki.secondlife.com/wiki/Eventlet
http://svn.secondlife.com/trac/eventlet
http://svn.secondlife.com/svn/eventlet/branches/beta-1

http://wiki.secondlife.com/wiki/Mulib
http://svn.secondlife.com/trac/mulib
http://svn.secondlife.com/svn/mulib/branches/beta-1

Question time: Since these libraries aren't specific to Second Life, it 
might make sense to use the Trac tickets and wiki for documenting them.  
On the other hand, there's some advantage to have all Linden development 
and bugs tracked in one single wiki/ticketer.  What do you all think?  
I'm particularly interested in hearing about effective uses of trac, and 
how we could make our use of it focused and productive.

We're also considering doing some sort of review/roadmapping process to 
figure out what set of changes would define a 1.0 release.  Are there 
good examples of such processes out there that we can emulate?

We'd like to improve the documentation and tests especially over the 
next few weeks.  I'm interested in feedback on your experiences with 
getting set up and running with these libraries, and any major holes in 
the documentation that inhibit understanding.  Please feel free to add 
to the 'Limitations' sections on the respective wiki pages.  I'm not 
sure of the best way to report bugs yet -- we can figure the proper way 
out later, but as a stopgap measure, filing bugs in the PJIRA under MISC 
will do.

-RYaN


More information about the SLDev mailing list