Hey, There was some interest in some code I had written a long time ago expressed at BoostCon - I believe I linked this before, but the location has changed. Specifically these are libraries inside of Mantra. These have not been modified in 2 years, so I wanted to know if there was any interest in them (and as such cause for me to update and submit them). If nobody is interested in them I will probably drop them, if people are interested I can look into cleaning them up and submitting. - boost::unformat - a logical reversal of boost::format (ie. scanf for boost::format): http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... Right now this only unformats into strings, and is not extensively tested, but it DOES work. If there is interest I will enhance it to unformat int a tuple, or something else (suggestions)? - Intrusive Tracing - the ability to activate various levels/styles of code-based tracing at runtime, and by logical code 'section'. http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/core/trace.... It uses macros - and I would like to expand it to more and better tracing capabilities, but what is there works and is VERY convenient. It even supports a 'transactional' mode of tracing, to avoid trace cross-talk. Tracing can be completely compiled away for production code. - Extension to program_options to allow for more robust checking of provided values. http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... Some of this functionality has been put into program_options, but not as nice as I'd like it (at least last I looked at it). This allows you to do things like validate the value provided (must match this regex, must fall within this range, must pass this check function). It also allows for more advanced things like value mapping (user uses value of 'INFO', which gets mapped to the enum LogLevel_t::INFO or whatever). It also allows 'chained' checks. This is probably showing its age though, there have been certain enhancements to program_options that makes some of the stuff here unnecessary. - Date/Time and Duration formatting (both to and from) functions: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... These were written before the date/time facets - but they are still useful. - Guarenteed event mechanism: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/service/eve... This handles its own thread pool (ie. minimum number of standby threads), and operates in such a way that it will guarentee an event is started EXACTLY when you want it, even if it has to spawn a new thread to do so. - In-process watchdog: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/service/wat... Relatively simple, but saves everyone else writing one :) - Various dispatching methodologies: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... These are message queues for different purposes. Each (except OTS) is backed by a thread pool that can resize based on high/low water marks. * MessageQueue - Single queue for a pool of threads. * ITS_MessageQueue - Implements a 'queue per thread' (with a 'transport' thread) to reduce lock contention by delivering messages to a worker thread for processing in bulk (includes 'fair' queueing). * Routed_MessageQueue - Adds a key to the message, guarenteeing that only one thread can process messages for a single key at any one time. - OTS_MessageQueue - Reverses ITS_MessageQueue, made for the 'other' side, ie. multiple threads sending data to a single thread (eg. a store and forward thread or something). In this case it only has a single thread (plus a collector), and has a queue per thread that PUSH's onto it instead. - Networking Stuff: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/net Written before ASIO was accepted - probably not required anymore, but it IS a simpler approach (ie. 3 classes, thats it). Supports select, poll and epoll. - Generic Data Storage Backend: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/storage This allows you to have a common interface to your storage back end, regardless of whether its an SQL database, Berkeley DB, XML file, etc. It also allows you to CODE a query, eg: Condition<C_LessThan>("col1", 3") && (Condition<C_EqualTo>("col2", "hello") || Condition<C_EqualTo>("col2", "world")) && Condition<C_Masked>("col3", FLAG_A | FLAG_B) This will then expand to an SQL expression for SQL DB's, or apply to data rows for non-SQL DB's - ie. it will work for all data sources. Right now I plan on re-writing this anyway to support: * Cross-table/database queries, better column limits and more operations: (http://www.neuromancy.net/mantra/trac/ticket/1) * Transactions & Cursors (http://www.neuromancy.net/mantra/trac/ticket/2) * An Object-based model (http://www.neuromancy.net/mantra/trac/ticket/3) But I would like to know if there is interest for this in the boost community or more specifically, in turning it into a boost module in its own right. - Store and Forward and Disk-Overflow: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/file/saf.cp... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/file/filebu... The SAF mechanism is there to implement guarenteed delivery of data, even if your application crashes. The FileBuffer provides disk-based overflow for memory-constrained situations (eg. where you have a socket, and you can get massive bursts of data to go out the socket, but cannot send it as fast as the burst - especially where you have thousands of such bursty connections). - Python bindings for some boost libraries: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/python/boost Right now I have bindings for boost::format, date_time and tribool. There was interest in these but nowhere to put them. In addition they need updating (especially date_time). I also plan on re-writing my Logging library: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... to be MUCH more efficient and flexible with regards to adding new logging back ends and formatting (http://www.neuromancy.net/mantra/trac/ticket/4). Sorry for the length of this post. Please let me know if you think some of these things would look good with a boost:: prefix :) PreZ :) BTW - I enjoyed BoostCon immensely, thanks again to the organizers and I enjoyed meeting many of you. This is an email you can contact me at :)
Preston A. Elder wrote:
- Generic Data Storage Backend: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/... and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/storage
This allows you to have a common interface to your storage back end, regardless of whether its an SQL database, Berkeley DB, XML file, etc. It also allows you to CODE a query, eg: Condition<C_LessThan>("col1", 3") && (Condition<C_EqualTo>("col2", "hello") || Condition<C_EqualTo>("col2", "world")) && Condition<C_Masked>("col3", FLAG_A | FLAG_B)
This will then expand to an SQL expression for SQL DB's, or apply to data rows for non-SQL DB's - ie. it will work for all data sources.
Right now I plan on re-writing this anyway to support: * Cross-table/database queries, better column limits and more operations: (http://www.neuromancy.net/mantra/trac/ticket/1) * Transactions & Cursors (http://www.neuromancy.net/mantra/trac/ticket/2) * An Object-based model (http://www.neuromancy.net/mantra/trac/ticket/3)
But I would like to know if there is interest for this in the boost community or more specifically, in turning it into a boost module in its own right.
Hm, interesting, I'll have to read through this a bit more because... As a result of some conversations, and some of the sessions, at BoostCon John and I started designing a schema definition and general database interfacing library. This is one area where we have considerable experience and some, IMO, interesting ideas. Here's part of a short example of what we are considering: template <typename C> struct Person : rsi::db::schema::table_def< C, Person<C> > { column id; column first_name; column last_name; column address; column mail_address; column phone; template <typename T> typename T::result_type operator()(T const & transform) { return transform( table("Person") <<= id("id") % integer[autoincrement] & not_null & primary_key <<= first_name("first_name") % character(50)[varying] & not_null <<= last_name("last_name") % character(50)[varying] & not_null <<= address("address_id") >> Address<C>().id <<= mail_address("mail_address_id") >> Address<C>().id <<= phone("phone") % character(20)[varying] & not_null ); } }; Obviously we'll be basing it on Eric's Proto library. The goal is to have separate the various database declarations from the database operations. This would be in the same style of separating containers and algorithms in the STL. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
As a result of some conversations, and some of the sessions, at BoostCon John and I started designing a schema definition and general database interfacing library. This is one area where we have considerable experience and some, IMO, interesting ideas. Here's part of a short example of what we are considering:
<snip>
Obviously we'll be basing it on Eric's Proto library. The goal is to have separate the various database declarations from the database operations. This would be in the same style of separating containers and algorithms in the STL.
Fun! Wow, I *really* need to get busy writing Proto's docs. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Rene Rivera" <grafikrobot@gmail.com> wrote
Here's part of a short example of what we are considering:
template <typename C> struct Person : rsi::db::schema::table_def< C, Person<C> > { column id; column first_name; column last_name; column address; column mail_address; column phone;
template <typename T> typename T::result_type operator()(T const & transform) { return transform( table("Person") <<= id("id") % integer[autoincrement] & not_null & primary_key
<<= first_name("first_name") % character(50)[varying] & not_null
<<= last_name("last_name") % character(50)[varying] & not_null
<<= address("address_id") >> Address<C>().id
<<= mail_address("mail_address_id") >> Address<C>().id
<<= phone("phone") % character(20)[varying] & not_null ); } };
Do I understand correctly that this code maps a database record into a C++ structure? Is it possible to enforce correct types here, instead of using universal "column" type? Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Rene Rivera" <grafikrobot@gmail.com> wrote
Here's part of a short example of what we are considering:
template <typename C> struct Person : rsi::db::schema::table_def< C, Person<C> > { column id; column first_name; column last_name; column address; column mail_address; column phone;
template <typename T> typename T::result_type operator()(T const & transform) { return transform( table("Person") <<= id("id") % integer[autoincrement] & not_null & primary_key
<<= first_name("first_name") % character(50)[varying] & not_null
<<= last_name("last_name") % character(50)[varying] & not_null
<<= address("address_id") >> Address<C>().id
<<= mail_address("mail_address_id") >> Address<C>().id
<<= phone("phone") % character(20)[varying] & not_null ); } };
Do I understand correctly that this code maps a database record into a C++ structure?
No :-)
Is it possible to enforce correct types here, instead of using universal "column" type?
It's possible, but not directly. Or at least as direct as an object-relational mapping would do it... The column type above only has a structural (as in declaring structure) function. It defines the fields the table has so that they can (a) be given a label in the def, (b) they can be referred to from other table definitions, and (c) they can be referred to from transforms. The generic declaration allows for any transformation on the schema. There would be transformations for data selection with queries, schema constructions, schema validations, object-relational mapping, etc. At the point when one does a transformation it would, at that point, check the types and applicability of the transformation based on the schema and the capabilities (the "C" above) which would restrict what can be done based on what is defined (schema) and what is possible (capabilities). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Maybe you can include me in on your conversations :) The end goal I am working towards is more something that works on 3 layers. The first layer is where you are more or less dealing with more low level stuff, more or less what I have now, where I can retrieve rows (which may be only a subset of all fields), insert, update, delete, etc. I want to expand it to handle cross-table stuff and views and more 'common' things (like max(), min(), count(), etc). But still dealing with more a less a vector of maps (vector enabling multi-row stuff and the map for key/value pairs). I'm using boost::variant for data items, and I find this very useful, but I want to be able to expand that to user-defined types. At this low level I also want to add stuff in to be able to identify what is supported natively by the backend (one thing I do this currently with is 'defaulted' fields for an insert where you can skip certain fields and the default value is taken - SQL supports this, others don't and I allow you to provide a function to provide the default value). The next layer I want to add transactional and cursor semantics - the ability to group subsequent operations. This means I will have to WRITE such things for databases that don't support it. The top layer is more what you are doing here, mapping an object to underlying storage. This can be done either via. 'loose' coupling (where we load an object and save it on destruction via. some smart pointer or something) or 'tight' coupling (individual fields are tied directly, and modifications can affect the database immediately). Either would also require some kind of cache more than likely. Obviously there is SOME interest in this :) I plan on doing something like this anyway, and possibly submitting it to Boost - would be a shame to duplicate effort :) The three bug reports explain the above in even more detail: http://www.neuromancy.net/mantra/trac/ticket/1 http://www.neuromancy.net/mantra/trac/ticket/2 http://www.neuromancy.net/mantra/trac/ticket/3 Using Proto would be a good idea for layer 3, I'm not sure how much use it can be for Layers 1 and 2 :) On Wed, 30 May 2007 15:15:28 -0500, Rene Rivera wrote:
Hm, interesting, I'll have to read through this a bit more because... As a result of some conversations, and some of the sessions, at BoostCon John and I started designing a schema definition and general database interfacing library. This is one area where we have considerable experience and some, IMO, interesting ideas. Here's part of a short example of what we are considering:
template <typename C> struct Person : rsi::db::schema::table_def< C, Person<C> > { column id; column first_name; column last_name; column address; column mail_address; column phone;
template <typename T> typename T::result_type operator()(T const & transform) { return transform( table("Person") <<= id("id") % integer[autoincrement] & not_null & primary_key
<<= first_name("first_name") % character(50)[varying] & not_null
<<= last_name("last_name") % character(50)[varying] & not_null
<<= address("address_id") >> Address<C>().id
<<= mail_address("mail_address_id") >> Address<C>().id
<<= phone("phone") % character(20)[varying] & not_null ); } };
Obviously we'll be basing it on Eric's Proto library. The goal is to have separate the various database declarations from the database operations. This would be in the same style of separating containers and algorithms in the STL.
Hrm, apologies if you get this twice, it seems my last post got lost :S On Wed, 30 May 2007 15:15:28 -0500, Rene Rivera wrote:
Hm, interesting, I'll have to read through this a bit more because... As a result of some conversations, and some of the sessions, at BoostCon John and I started designing a schema definition and general database interfacing library. This is one area where we have considerable experience and some, IMO, interesting ideas. Here's part of a short example of what we are considering:
<-- SNIP --> I was envisioning the database system in three layers. The first would be the more base layer - where you define the data schema layout (in your database, which may have NO relation to your objects), and like my current interface, you can do your basic operations (insert, select, delete, update + some others) there. Here you would define also things like constraints and such. You still define these in a storage agnostic way, but you you are still restricted more or less to one-shot commands and definitions. Here is where the query language would live, which more or less is like my current one, but with support for cross-table/database actions and such. I more or less have this I just need to expand it and make it more capable. I also want to add a 'capabilities' class so each back end can define what it can do natively and what higher layers (up to and including the user) are required to provide for certain things. I have a rudimentary version of this with my support for 'defaulted' values (ie. some backends can do it natively, some you have to provide your own callback for this functionality). For some more information see: http://www.neuromancy.net/mantra/trac/ticket/1 The second layer would be where I have transactions and cursor support. More or less any operation that can occur across individual function calls and may need some kind of state maintained (or some resource acquired and released). This is a very tricky thing to do, as my goal is not just to support SQL databases, but ANY data storage backend - including Berkeley DB, XML files - hell, even INI files. So for those that don't support it natively I will have to write my own transaction system. The task for this is: http://www.neuromancy.net/mantra/trac/ticket/2 The third layer is object integration. This is more in line with what you posted. Allowing you to bind your data to the underlying storage so you don't have to interact with the storage mechanism directly. In fact, I was considering two forms of binding (I don't know if I'll do both or just one). - 'Loose' binding where you retrieve an object whole through some kind of smart pointer, then modify it and when it goes out of scope (or by explicit action) it will 'write' the data back (either to the DB or the transaction if you are in a transaction) by more or less populating a map with either all fields or the modified ones. I have implemented this before (using boost::serialization) and it works well. - 'Tight' binding, where each data item is bound to a particular field in your database The other is 'tight' binding where each field is tightly coupled to a piece of data in your database (though not necessarily the same database or table or whatever). Either querying OR updating the field can trigger a lookup or write in the most extreme case (though in most cases some kind of caching would be going on here for efficiency's sake). This is more what your layout looks like. Finally: http://www.neuromancy.net/mantra/trac/ticket/2 I will say I *DO* like the idea of using boost::proto - it cleans up the schema definition and query languages very well - and makes tight binding look much cleaner. Anyway, it seems there is indeed interest in this, but I don't think duplicated work is the way to go - we should probably work together on something like this. Though right now I only really have a good chunk of Layer 1 done (with multiple backends - as you can see from the source tree). It is certainly not throw away code though. Preston. Hopefully this posts successfully this time :)
on Wed May 30 2007, "Preston A. Elder" <prez-AT-neuromancy.net> wrote:
Sorry for the length of this post. Please let me know if you think some of these things would look good with a boost:: prefix :)
Hi Preston, It was nice meeting you at BoostCon. Thanks for posting these. Just wanted to suggest you might get a better response if you started separate threads for each of your potential contributions. Regards, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Yah, I just didn't want to clutter up the boost list with Mantra stuff ;) On Wed, 30 May 2007 20:39:47 -0400, David Abrahams wrote:
on Wed May 30 2007, "Preston A. Elder" <prez-AT-neuromancy.net> wrote:
Sorry for the length of this post. Please let me know if you think some of these things would look good with a boost:: prefix :)
Hi Preston,
It was nice meeting you at BoostCon. Thanks for posting these. Just wanted to suggest you might get a better response if you started separate threads for each of your potential contributions.
Regards,
You've been holding back. Most if not all of your libraries would be much appreciative. Below are my top 5 needs. 1) boost::unformat 2) Date/Time and Duration formatting (both to and from) functions The datetime facets doesn't accept 5/7/2007 but requires 05/07/2007. Anything that could fix this problem would be appreciated. Further if there was one that could understand a variety of formats would be even better. 3) Generic Data Storage Backend (Though you may want to consider collaboration with those working on a boost database api 4) tracing in debug and release builds 5) logging; even better if physical limits, circular buffer constraints could be imposed similar to windows event log so that files don't have to be deleted periodically/managed -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Preston A. Elder Sent: Wednesday, May 30, 2007 3:04 PM To: boost@lists.boost.org Subject: [boost] Interest from BoostCon Hey, There was some interest in some code I had written a long time ago expressed at BoostCon - I believe I linked this before, but the location has changed. Specifically these are libraries inside of Mantra. These have not been modified in 2 years, so I wanted to know if there was any interest in them (and as such cause for me to update and submit them). If nobody is interested in them I will probably drop them, if people are interested I can look into cleaning them up and submitting. - boost::unformat - a logical reversal of boost::format (ie. scanf for boost::format): http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ core/unformat.h Right now this only unformats into strings, and is not extensively tested, but it DOES work. If there is interest I will enhance it to unformat int a tuple, or something else (suggestions)? - Intrusive Tracing - the ability to activate various levels/styles of code-based tracing at runtime, and by logical code 'section'. http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ core/trace.h and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/core/trace. cpp It uses macros - and I would like to expand it to more and better tracing capabilities, but what is there works and is VERY convenient. It even supports a 'transactional' mode of tracing, to avoid trace cross-talk. Tracing can be completely compiled away for production code. - Extension to program_options to allow for more robust checking of provided values. http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ core/typed_value.h Some of this functionality has been put into program_options, but not as nice as I'd like it (at least last I looked at it). This allows you to do things like validate the value provided (must match this regex, must fall within this range, must pass this check function). It also allows for more advanced things like value mapping (user uses value of 'INFO', which gets mapped to the enum LogLevel_t::INFO or whatever). It also allows 'chained' checks. This is probably showing its age though, there have been certain enhancements to program_options that makes some of the stuff here unnecessary. - Date/Time and Duration formatting (both to and from) functions: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ core/datetime.h These were written before the date/time facets - but they are still useful. - Guarenteed event mechanism: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ service/events.h and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/service/eve nts.cpp This handles its own thread pool (ie. minimum number of standby threads), and operates in such a way that it will guarentee an event is started EXACTLY when you want it, even if it has to spawn a new thread to do so. - In-process watchdog: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ service/watchdog.h and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/service/wat chdog.cpp Relatively simple, but saves everyone else writing one :) - Various dispatching methodologies: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ service/messagequeue.h http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ service/its_messagequeue.h http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ service/routed_messagequeue.h http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ service/ots_messagequeue.h These are message queues for different purposes. Each (except OTS) is backed by a thread pool that can resize based on high/low water marks. * MessageQueue - Single queue for a pool of threads. * ITS_MessageQueue - Implements a 'queue per thread' (with a 'transport' thread) to reduce lock contention by delivering messages to a worker thread for processing in bulk (includes 'fair' queueing). * Routed_MessageQueue - Adds a key to the message, guarenteeing that only one thread can process messages for a single key at any one time. - OTS_MessageQueue - Reverses ITS_MessageQueue, made for the 'other' side, ie. multiple threads sending data to a single thread (eg. a store and forward thread or something). In this case it only has a single thread (plus a collector), and has a queue per thread that PUSH's onto it instead. - Networking Stuff: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ net and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/net Written before ASIO was accepted - probably not required anymore, but it IS a simpler approach (ie. 3 classes, thats it). Supports select, poll and epoll. - Generic Data Storage Backend: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ storage and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/storage This allows you to have a common interface to your storage back end, regardless of whether its an SQL database, Berkeley DB, XML file, etc. It also allows you to CODE a query, eg: Condition<C_LessThan>("col1", 3") && (Condition<C_EqualTo>("col2", "hello") || Condition<C_EqualTo>("col2", "world")) && Condition<C_Masked>("col3", FLAG_A | FLAG_B) This will then expand to an SQL expression for SQL DB's, or apply to data rows for non-SQL DB's - ie. it will work for all data sources. Right now I plan on re-writing this anyway to support: * Cross-table/database queries, better column limits and more operations: (http://www.neuromancy.net/mantra/trac/ticket/1) * Transactions & Cursors (http://www.neuromancy.net/mantra/trac/ticket/2) * An Object-based model (http://www.neuromancy.net/mantra/trac/ticket/3) But I would like to know if there is interest for this in the boost community or more specifically, in turning it into a boost module in its own right. - Store and Forward and Disk-Overflow: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ file/saf.h and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/file/saf.cp p and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ file/filebuffer.h and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/file/filebu ffer.cpp The SAF mechanism is there to implement guarenteed delivery of data, even if your application crashes. The FileBuffer provides disk-based overflow for memory-constrained situations (eg. where you have a socket, and you can get massive bursts of data to go out the socket, but cannot send it as fast as the burst - especially where you have thousands of such bursty connections). - Python bindings for some boost libraries: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/python/boost Right now I have bindings for boost::format, date_time and tribool. There was interest in these but nowhere to put them. In addition they need updating (especially date_time). I also plan on re-writing my Logging library: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra/ log to be MUCH more efficient and flexible with regards to adding new logging back ends and formatting (http://www.neuromancy.net/mantra/trac/ticket/4). Sorry for the length of this post. Please let me know if you think some of these things would look good with a boost:: prefix :) PreZ :) BTW - I enjoyed BoostCon immensely, thanks again to the organizers and I enjoyed meeting many of you. This is an email you can contact me at :) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Arkadiy Vertleyb -
David Abrahams -
Eric Niebler -
Jarrad Waterloo -
Preston A. Elder -
Rene Rivera