On Tue, 2 Mar 2004 11:49:50 +1300, scott wrote
I have been working on a small library that has become reasonably useful and possibly of interest to someone else. It's also become fairly large.
I am quite interested in this library getting "boosted" but even given that there is substance to the library its scope is a bit of a problem; its quite large. It was started as
In general, large libraries are a problem in boost -- for lots of reasons. I'd encourage you to break things down into useable pieces and focus on getting the most useful parts boostified. If it is really large, it will be a long road...
...snip.... A breakdown of the incidental technologies tackled by this library follows;
* multi-threading building block classes
Yes, you'all have been discussing some interesting possible extensions for AO and such. Sorry I haven't been able to keep up with all of it. Anyway, these would be a nice contribution in my view.
* network representation of structured data (variants)
How different from boost.Variant?
* saving and loading of network data (persistence)
Robert Ramey has done a huge amount of work on this -- have you checked it out? This library has been through one review cycle and I believe Robert has now addressed all the big concerns. My sense is that his library is the 'one' for persistence.
* interactive machines (inter-thread messaging)
Another needed extension of boost.threads all would agree.
* stateless and stateful machine representation
How does this contrast with the boost.fsm (finite state machine) implementation in the boost-sandbox by Andreas Huber? I think the project has been dormant for awhile although I notice the docs page was update in Feb 2004. Anyway, it is quite interesting.
* code generation of network data and machine skeletons
Not sure this would really be appropriate for a boost library...
* message forwarding (distributed messaging) * transparent remote machines (proxies for inter-process messaging)
Are you talking about multi-cast messaging, publish-subscribe, method invocation, or what?
* support for multiple encodings, e.g. binary, text, XML...
Also covered by the persistence library.
...snip example...
I am very happy to work towards a boosted version of a subset of this work cos basically it seems too large to be a prospect
Agree.
otherwise. This subset would be in the area of mutli-threading building block classes, i.e. an "alternate threading model". However, after the recent exchange of related and interesting messages, I felt compelled to "come clean" with some background.
Hmm, hope I'm not jumping in in the middle without context. In any case, I'm agreeing with the need to focus. Jeff