[boost] Adobe Source Libraries, GIL, and Boost

From: Sean Parent (sparent_at_[hidden])
Date: 2006-07-03 15:09:04

Hi Jeff,
> I'll just say a public thanks to yourself, Adobe, and the folks  
> behind ASL for
> dipping their toe in the open source water. I think it will take  
> several
> years to see the full effect, but it's very exciting to me to see  
> you guys
> getting a chance to bring these ideas out into the world.
Probably more than several years (given that it isn't clear the  
Generic Programming has caught on yet) :-(
> > I will also support anyone who would like to borrow portions of ASL
> > to contribute them to Boost.
>
> This is really great -- it seems there is much common activity with  
> other
> things happening in Boost (see below).
>
> > 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.
> > Range Based Algorithms (using the boost range library) <http://
> > opensource.adobe.com/group__standard__extensions.html>
> >
>
> 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!
> > ZUIDs <http://opensource.adobe.com/classadobe_1_1zuid__t.html>
>
> Hmm, I guess I would think zuid should be its own little library.  
> There is
> already a GUID in the vault which again might benefit from  
> collaboration here:
>
> http://www.boost-consulting.com/vault/index.php -- guid_v3.zip
Interesting - this is not quite a conforming GUID (deviates in many  
of the same ways that ZUIDs do from the specification but I try to be  
honest and not call them GUIDs...

<http://www.uddi.org/pubs/draft-leach-uuids-guids-01.txt>

AFAICT the node ID in the boost code is purely dependent on the clock  
- this makes the entire ID uniqueness of the ID a function of time  
(making for a fairly high probability of collision). The ZUID code  
includes machine specific and process specific information in the  
node generation and has code to synchronize threads to avoid  
collisions from requesting IDs from separate threads at the same time.

Anybody know how to contact Andy Tompkins to see if he wants to  
collaborate?
> 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.

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!)

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.
> > regular_object <http://opensource.adobe.com/
> > classadobe_1_1regular__object.html>
> > This is a generalization of value_t (and boost any) - the idea is to
> > be able to parameters an "any" object by concept. Mat Marcus has  
> been
> > doing a fair amount of work with this library. Needs better docs and
> > tutorial.
>
> Interesting. Don't know of any current Boost work here.
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/>
> > Copy-On-Write <http://opensource.adobe.com/
> > classadobe_1_1copy__on__write.html>
>
> I guess the ever-languishing policy_pointer is the closest Boost work.
A key simplification here was realizing that copy-on-write deals with  
values, not pointers.
> > 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.
> Hopefully people will make you very busy :-)
Already you've given me some nice references. Thanks.

Sean