From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-03 21:53:54
Sean Parent wrote:
> Hi Jeff,
>>> Some libraries that I think would be interesting to get into Boost
>>> with some comments about what I see as still needing to be done.
>>> Forest <http://opensource.adobe.com/
>> We have an active SOC project to build a generic tree...
> Are there links to these on port 80? I can't get to 8443 from inside
There isn't I'm afraid. There's more here:
including a pointer to the developers blog. It has some of the design stuff,
but not all of it.
>> Eric Niebler has written some range algorithms in the vault -- be
>> nice to see if he's covered all the ones you'all have:
> There is some nice work here to specialize for the standard
> containers - something I hadn't considered and isn't part of my
> library. Thanks for the pointer!
>>> ZUIDs <http://opensource.adobe.com/classadobe_1_1zuid__t.html>
I'll defer to the new thread on this topic.
> Anybody know how to contact Andy Tompkins to see if he wants to
I don't. Searching the list archive the last message I found was in 2004...I
guess that doesn't bode well...
>> I don't know if we've really found an active maintainer for
>> Boost.Threads....library abandonment is starting to become a much
>> bigger issue for Boost as time goes on :-(
> Maintenance for any large library is problematic. I ask that for each
> release, my developers improve one existing library (both
> documentation and code) - we release once a month so this helps to
> keep things from stagnating. Right now I don't mandate _which_
> library is improved but at some point I'll have to start dictating
> the priority. Of course, the folks working for me aren't quite
> volunteers so I can get away with that. But some possible suggestions
> for boost -
> 1. Speed up the release cycle - I would try to get two two releases a
> year at a minimum. Just upping the release pace will help avoid
We all want that -- there's been some discussion of how to provide a more
continuous release process. Hopefully that will improve things.
> 2. Make maintenance part of the cost of admission - "We're really
> happy to take your GIL submission, but part of contributing to Boost
> is to assist with the general maintenance. Here's a short list of
> tasks we'd like you to take on..." (Sorry Lubomir!)
Yeah, well I'm afraid the cost of admission is already a pretty high -- adding
a non-related task sounds like it might kill off some authors to me.
> I'm constantly looking at ways that we can improve this with ASL -
> honestly the library as it stands today is large enough that I could
> burn my entire team just maintaining and improving the current
> libraries without ever adding any more (at least for the next few
> years). Balancing this with adding new libraries and showing forward
> progress is very difficult.
Yep -- been there before. The good thing is that the folks working on ASL are
being paid to work on it. Most Boost authors don't get paid -- at least not
directly. So there's a simple limit there on how much time they can spend and
'feed their families' as well.
>>> regular_object <http://opensource.adobe.com/
> We're currently putting a fair amount of emphasis on this work - the
> general idea is that the requirement of polymorphism comes from the
> requirement to apply algorithms to heterogeneous collections of
> objects. Hence - runtime polymorphism should be based on Concepts and
> cannot be properly described by intrusive means (such as
> inheritance). I'm currently collaborating on a paper on the topic
> that I'm hoping to have ready for LCSD <http://lcsd.cs.tamu.edu/2006/>
Cool, I'll be at OOPSLA so I'll be there for sure :-) I read through you
slides on this subject and I found the case quite compelling -- nothing quite
like the 'here's ugly code' to 'here's beautiful code' story to sell a programmer.
>>> XML Parser <http://opensource.adobe.com/
>> There is a Boost xml, but I haven't seen much Boost activity here.
>> Property tree does some too, but full XML support is hard enough that it
>> will be hard to do in Boost.
> We're getting close to a complete XML parser - this is not a DOM, the
> idea is that a DOM would be a separate library that could be used
> with the parser - but the parser can be used just fine without a DOM.
Excellent -- XML parsing is certainly something frequently requested in Boost.
I don't think you need a DOM parser, btw, just one that meets the Boost
standards -- which I'm sure yours will.
>> Hopefully people will make you very busy :-)
> Already you've given me some nice references. Thanks.