[260] in BarnOwl Developers

home help back first fref pref prev next nref lref last post

Re: Regarding owl development

daemon@ATHENA.MIT.EDU (James M. Kretchmar)
Thu Oct 29 18:04:14 2009

Resent-From: nelhage@mit.edu
Resent-To: barnowl-dev-mtg@charon.mit.edu
Date: Tue, 31 Oct 2006 01:13:28 -0500
From: "James M. Kretchmar" <kretch@MIT.EDU>
To: dirty-owl-hackers@mit.edu
Cc: nygren@mit.edu
In-Reply-To: <454596C4.4040100@mit.edu>

Ok, so a few topics here:

  1. Future plans for owl
  2. Collaborative development
  3. Specific changes so far

First future plans, as you asked for.  Future plans for Owl look
something like:

  - Outstanding bug fixes
  - OTR support
  - Jabber support
  - (possible) Generic gaim plugin support
  - Replace AIM library
  - AIM chatroom support
  - Other protocol support (IRC etc.)
  - Rewrite in python
  - Rearchitect to separate UI from message engine
  - Curses UI improvements (list selectors etc.)

although it's not fixed in stone.  Also some of those are
interdependent.  Generic gaim plugin support might obviate the need
for replacing the AIM library, and would definitely eliminate the need
for direct support of other protocols like IRC.  A rewrite in python
would include the work to better separate the UI from the message
engine.

A few things have been in the works, although as you rightly point
out, very slow to progress.  I was gearing up a release for
outstanding bug fixes and OTR support a couple of months ago, but the
whole thing stalled out when the OTR support turned out to be buggy.
I also heard from a strong developer that he might have official time
to add jabber support to Owl in the near future, although I don't know
if that will pan out or not.

Second topic: collaborative development.  I've definitely been the
bottleneck on development for a while.  Ideally, I'd like to keep a
single owl project line since diverging projects often cause pain for
the common user and it's been an explicit philosophy of owl from the
start to function well for both the expert and the novice.  I can see
two paths from here:

  1. If we find we're definitively or irreconcilably at odds over the
     architectural direction of owl there won't be any choice but to
     fork off a new project.  My guess is this isn't the case, but I
     don't know for certain.  If it is the case we should talk about
     how to work out naming your branch to avoid future confusion.

  2. If we find that we're all more or less on the same page with the
     architectural directions I want for Owl, then I think we mostly
     have a problem with the mechanics of making collarborative
     development work.  I'm open to all suggestions here as I'm
     clearly getting too used to the corporate world.  Maybe we should
     open up much wider access to write to the CVS respository.  If we
     do that along with discussion in CRs about proposed
     implementations before coding, and have good pre-beta testing
     that might work out fine.

Third topic: specific changes you've got.  Tell me more about the
changes you've made.  Exposing more of the C functionality to the perl
config sounds fine as long as it's not something that's going to
obviously break configs in future versions when we change C
functionality.  What kind of things are exposed?  Also, using that to
work in Jabber support through Perl is very nifty, although I don't
think we should consider that "real" jabber support (i.e. if folks
want to use that to define a jwrite in their owlconf that's cool, but
I wouldn't want to distribute owl with a built-in jwrite that relies
on Net::Jabber).

BTW, I've cc'd nygren who's been heavily involved with parts of owl
development in the past.

kretch

On Mon, Oct 30, 2006 at 01:08:04AM -0500, Alejandro R. Sedeno wrote:
> kretch,
> 
> The owl hacker community appears to have achieved some critical mass
> last week. We've taken owl from cvs and dropped it into an svn
> repository where have been hacking on it together. We've incorporated
> the patches on bugzilla, and extended its functionality in new and
> interesting ways.
> 
> We would like to collaborate on owl, but from our point of view owl
> development appears to have stagnated; the last release is already over
> a year and a half old. We would like to know what your plans are for owl
> before we fork and release our own version.
> 
> We'd also like to share some of the ideas we've been working on. Over
> the course of the last week, we've exposed more of owl's C functionality
> to perl, allowing it to hook into main loop and inject arbitrary
> messages. We've taken that base and and the owlconf system I (asedeno)
> mailed you about in Jan 2005, and in the past couple of days have added
> preliminary jabber support using Net::Jabber.
> 
> The svn repository is available at
> /afs/athena.mit.edu/user/n/e/nelhage/svn/dirty-owl-hacks/
> readable by the public LIST:dirty-owl-hackers.
> 
> We look forward to hearing from you,
> 
> Those dirty owl hackers,
> dirty-owl-hackers@mit.edu
> 

home help back first fref pref prev next nref lref last post