Lots of things on my plate ;)
If you want to make sure a feature is implemented sooner, drop me a note: http://torjo.com/contact.html
normal destination::stream_ptr - just like stream, but hold the stream as a shared pointer. Thus , we won't have to worry about outliving the stream.
normal make it possible to initialize from a file - thus we'd need no caching! also allow for extra syntax for the named_writer - {} - to be applied to a destination this way, you can specify some extra formatters to be applied only to a specific destination
normal on_dedicated_thead - remove dependency on boost::thread
normal on_dedicated_thead - I should see it I use logger::always_accurate increases logging time as opposed to some caching strategy. I'm asking this because even if we were to use a critical section on the base_type writer's operator(), this will always* happen on the dedicated thread. Thus, I would think it should have very small overhead
normal must have helper to call on on_destructed - like, to be able to write to cout,etc
normal turn_cache_off() -> find better name, like mark_init_complete() (add a function named like this to call turn_cache_off()).
normal have a logger_with_filter class, to make using the lib easier (this would hold the logger and the filter).
high destination::stream - have flush() and flush_each_time
high writer::named_write<> need to allow tags by default, here!
high scenario::use class - have gather and write typedefs !!! this way we can have: named_logger< finder::gather , writer::named<finder::writer> > same goes for logger_format_write class.
normal make it so that I use BOOST_LOG_USE_WCHAR_T as little as possible for instance, it's not needed in cout_t, cerr_t.
high cut down compile time: make it compile faster (most likely improve use_format_write, etc)
high named_write<> - due to Modifying a manipulator while it's used - whenever I modify the format and/or destination string, i need to add/delete all formatters and/or destinations in order to avoid that scenario TOTHINK
high logger_format_write<> should be just like other find classes - have logger_format_write<>::type this should uncomplicate code a bit - at least specializing logger_to_gather/writer for logger_format_write<>.
normal profiler - we can care about threads as well (that is, for instance, when logging on another thread, see how much time it takes from the threads that actually work)
low in the same way I've created convert_to_base(), I can create a convert_to_top(), on top of which I can create my own way to gather message, and then write it.
low when leaking/not leaking loggers/using after_destroyed - have a templated class that allows this (only if users ask for it) I could probably do a bit more about caching as well - however, in this case, I should allow for macros to be visible in client code (for instance, if client wants BOOST_LOG_BEFORE_INIT_USE_CACHE_FILTER)
high test TSS on vs2003 and gcc/pthreads
normal allow to see how much time logging actually takes
low configuration : should allow the library to be configured at runtime, from a file, much like log4j note: see formatter::named_spacer, destination::named
low hierarchical logs : just like log4j - be able to have some logs inherit from parent logs I can implement this in multiple ways - one would be to use function names (BOOST_CURRENT_FUNCTION) and see the namespace/class name from there. Or, I could implement it using __FILE__.
low have a "class"/"function" filter
low composite_filter
low Design: logged assert. I believe log library needs to provide support for custom assert. Such assert would log into log file and invoke system assert depends in assert level. It could be an addon to core functionality.
normal Allow using log from DLL and EXE (on Windows). Same for Linux. This should normally work - just need to explain how.low new formatter: limit the text to gives maximal length. It may happend the dump is unexpectedly large and would fill disk/overwrite cache/take too much time/be unreadable. Limiting one log size would help here a lot and would relieve end user of doing it manually.
normal quite often I am not interested not in absolute time (2005/12/11 16:33) but in time offset from some event. I suggest to add API:
normal new formatter: thread ID (both Win32 and POSIX) is of low use. I suggest to add API to specify string name as alternative to thread ID formatter.set_current_thread_name("gui thread");
normal Time string cashing time and time_strf calls are not cashed. It's a lot of work for nothing. Note: should use TSS
normal Design: hexdump. I believe log library needs to provide support for dumping memory in hex format on log file.normal new destination : to Event log
normal shared_memory is to use interprocess lib.low add "for documentation, see http://www.boost.org/lib/logging/" to each file
low have a document with differences from v1 and v2
normal explain BOOST_LOG_USE_SIMPLE_LOG_IF_FILTER (defining_logger_macros)
normal explain about cachestring clases
normal about is_generic formatters/destinations (note that I might have already written about this)
low Nice to have docs wish: a page discussing stranghts of this logger vs other common ones (log4cpp etc).
normal Documentation about performance of the library is missing - absolute times, # of dynamic allocations per typical log, etc.
high For formatters/destinations - make it easier to see - not necessary from examples. By looking at the namespace itself, it contains other stuff as well. See if I can use @ ingroup or something
normal Explain about config files - you can use named_spacer,named.
high explain about common_base()
high on_dedicated_thread : explain about manipulating it - while pause() TOTHINK if I can automate this
normal "Manipulating thy manipulator" - another way is to create another manipulator, delete the current one , and add the new one i should explain that this could not work immediately because of caching.
normal scoped logs - scoped_write_msg - explain that you need to implement this in case you have your own gather.read_msg().out() class