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

Hi Jeff, 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...

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_

...

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

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