Re: [boost] Adobe Source Libraries, GIL, and Boost

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/ 
>> group__asl__tutorials__forest.html>
>>> .....
>> We have an active SOC project to build a generic tree...
>>
>> https://boost-consulting.com:8443/trac/soc/wiki/tree
>> https://boost-consulting.com:8443/trac/soc/wiki/tree/design
> Are there links to these on port 80? I can't get to 8443 from inside  
> Adobe.

There isn't I'm afraid.  There's more here:

http://code.google.com/soc/boost/appinfo.html?csaid=E17EA7C7C537C131

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:
>>
>> http://www.boost-consulting.com/vault/index.php? 
>> &direction=0&order=&directory=Algorithms
> 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!

Sure :-)

>>> 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  
> collaborate?

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  
> stagnation.

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/
>>> classadobe_1_1regular__object.html>
 >
> 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/
>>> classadobe_1_1xml__parser__t.html>
>> 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.
>>
>> http://www.boost-consulting.com/vault/index.php? 
>> direction=0&order=&directory=Progamming%20Interfaces
 >
> 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.

You're welcome.

Jeff