# -*- mode: org -*-

#+TODO: TODO BLOCKED | DONE CANCELED

* CANCELED [#C] Switch to Module::Build
  CLOSED: [2010-12-31 Fri 12:03]
  - CLOSING NOTE [2010-12-31 Fri 12:05] \\
    Unless I see a compelling reason to switch to Module::Build, then just
    keep using ExtUtils::MakeMaker

  Unsure if I want to do this or not.  Still need to weigh the
  benefits to doing this

* DONE [#B] Have Utils handle more than one Logger
  CLOSED: [2011-01-11 Tue 08:28]
  - CLOSING NOTE [2011-01-11 Tue 08:29] \\
    Unit tests passed on OpenSolaris so can close out this task

  Currently L::F::U can handle only one Logger.  Extend API to allow
  for multiple logging objects

  [2011-01-07 Fri 15:35] First draft committed.  Note that there are
  issues with logger objects going out of scope that need to be
  addressed.  See dc8ac22 for details.

  [2011-01-10 Mon 12:04] Multiple logger support developed and merged
  to master.  Unit tests passed on all platforms although still need
  to test OpenSolaris.

** Possible API

*** AddLog(<Logger>)

    Adds given Log::Fine::Logger object to internal store

*** SwitchLog(<name>)

    Switch to Logger object specified by "name"

** Another Idea

   Have OpenLog() accept a name argument.  If the name is defined,
   then open that logger, if not, create a new logger object.

   Also, add support for listing loggers to Log::Fine

* CANCELED [#C] Add tutorial for defining Level sub-classes
  CLOSED: [2010-11-24 Wed 11:54]
  - CLOSING NOTE [2010-11-24 Wed 11:55] \\
    In the rare instances where someone would want to define their own
    level classes, people should be able to figure out the API simply by
    looking at either Syslog or Java subclasses as examples.

* DONE [#A] Document git repository
  CLOSED: [2010-11-24 Wed 11:52]
  - CLOSING NOTE [2010-11-24 Wed 11:53] \\
    See [[https://github.com/cfuhrman/log-fine/commit/26dee0df99b40f315a1ad7ba336e913391b9724e][log-fine/26dee0f]]

  Add note about the new git repository

* DONE [#B] Add Formatter Template class
  CLOSED: [2010-12-31 Fri 12:01]
  - CLOSING NOTE [2010-12-31 Fri 12:02] \\
    Done

  Add a template class to allow the user to easily build log message
  templates.  Perhaps use message layout options from [[http://search.cpan.org/dist/Log-Handler/lib/Log/Handler.pm][Log::Handler]]?

** Available options

   | %%TIME%%      | Timestamp            |
   | %%LEVEL%%     | Log Level            |
   | %%MSG%%       | Log Message          |
   | %%PACKAGE%%   | Caller Package       |
   | %%FILENAME%%  | Caller filename      |
   | %%LINENO%%    | Caller line number   |
   | %%SUBROUT%%   | Caller Subroutine    |
   | %%HOSTSHORT%% | Short Hostname       |
   | %%HOSTLONG%%  | Long (FQDN) Hostname |
   | %%LOGIN%%     | User Login           |
   | %%GROUP%%     | User Group           |

*** DONE Document POD
    CLOSED: [2010-11-25 Thu 20:53]
    - CLOSING NOTE [2010-11-25 Thu 20:53] \\
      Documented

*** DONE Think about {use_real_user_id} name
    CLOSED: [2010-11-26 Fri 11:24]
    - CLOSING NOTE [2010-11-26 Fri 11:24] \\
      See [[https://github.com/cfuhrman/log-fine/commit/c101f8a62b032ed7bfae0f9f3ec39d72b435191a][log-fine/c101f8a]]

    This option might be confusing to the casual programmer.  Perhaps
    having a {use_effective_id} attribute would be better?

    Some ideas:

     - Do not cache user & group when {use_effective_id} is set?

     - Add {no_cache} option to constructor

     - Dynamically enable/disable Caching via API?

     - Use global static storage of user & group?

     - Use global static storage of filename and hostname?  These
       aren't as likely to change so global static storage might be a
       better idea

    [2010-11-26 Fri 11:23] Decided to keep attributes as hash keys.  I
    did switch to using {use_effective_id}.

*** DONE Create _filename method
    CLOSED: [2010-11-26 Fri 11:22]

    The name of the program isn't likely to change so cache it.  Maybe
    make this a global static?

*** DONE Make note that placeholders are case-insensitive
    CLOSED: [2010-11-26 Fri 11:22]
    - CLOSING NOTE [2010-11-26 Fri 11:22] \\
      See [[https://github.com/cfuhrman/log-fine/commit/c101f8a62b032ed7bfae0f9f3ec39d72b435191a][log-fine/c101f8a]]

*** DONE Optimize Template.pm
    CLOSED: [2010-12-31 Fri 12:00]
    - CLOSING NOTE [2010-12-31 Fri 12:01] \\
      See [[https://github.com/cfuhrman/log-fine/commit/0325b031a609aba48d6eeadf2885c9aa0fc235d2][log-fine/0325b031]]

    Template.pm works although it may be a little on the slow side.
    Attempt to optimize.

    While I'm thinking about it, come up with some stress tests so I
    can get some hard figures

**** DONE Create stress test script
     CLOSED: [2010-12-02 Thu 22:37]
     - CLOSING NOTE [2010-12-02 Thu 22:38] \\
       See [[https://github.com/cfuhrman/log-fine/commit/1ed98bbfc896213aeda27ea2b1f14b33a13e92f1][log-fine/1ed98bbf]]

     Create stress script to get some hard figures on how fast
     Log::Fine can output messages.

* DONE Break up 04-formatter.t tests
  CLOSED: [2010-12-01 Wed 12:12]
  - CLOSING NOTE [2010-12-01 Wed 12:13] \\
    Done.  See [[https://github.com/cfuhrman/log-fine/commit/2c14f64d436513c8af2191a061bf571c93a02067][log-fine/2c14f64]]

  04-formatter.t has two skipped sections which probably doesn't jive
  well.  Break up 04-formatter.t tests into 2 separate test chunks.
  Perhaps an 0x-formatter-template.t file

* CANCELED Figure out name for GetLogName()
  CLOSED: [2011-03-18 Fri 16:08]
  - CLOSING NOTE [2011-03-18 Fri 16:09] \\
    GetLogName() has been done away.  Similar functionality can be
    obtained via CurrentLogger()->name()

  I don't like GetLogName() which doesn't seem to follow the rest of
  the method naming convention used in Log::Fine.  Figure out a better
  name ... say, CurLogName()?

  I'd like to think on this a while

** Potential Names

   - CurLogName()

   - ActiveLogName()

   - LogName()

   - CurrentName()

** Alternative

   Implement Log::Fine->name() for returning the name of an object


* DONE Re-implement logger tracking in Utils
  CLOSED: [2011-03-18 Fri 16:09]
  - CLOSING NOTE [2011-03-18 Fri 16:09] \\
    Done

  The current way that Utils tracks multiple loggers is a bit on the
  sloppy side.  Try to make the internals more intuitive

** What needs to be stored?

   - Internal Log::Fine object

   - Pointer to current Logger

** What needs to be provided to the programmer?

   - name of current logger (is this needed?)

   - list of currently defined logger names (ListLoggers)

   - Way to open a logger objects (OpenLog)

   - Way to switch logger objects (OpenLog)

   - Log function (Log)

** DONE Add unit tests for $obj->name()
   CLOSED: [2011-03-18 Fri 17:02]
   - CLOSING NOTE [2011-03-18 Fri 17:02] \\
     Done

   Add unit tests for $obj->name()

** CANCELED Additional Utils unit tests
   CLOSED: [2011-03-19 Sat 12:33]
   - CLOSING NOTE [2011-03-19 Sat 12:33] \\
     Canceled

   Add some additional unit tests to Utils to give a thorough workout

** TODO Add one more unit test for Log::Fine::Handle::Syslog

   Need a separate unit test for testing Log::Fine::Handle::Syslog
   with a different facility so as to avoid the situation encoutered
   in [[https://rt.cpan.org/Ticket/Display.html%3Fid%3D63026][CPAN RT Ticket #63026]]

* DONE [#B] Clean up unit tests                                       :tests:
  CLOSED: [2011-03-28 Mon 16:07]
  - CLOSING NOTE [2011-03-28 Mon 16:07] \\
    Completed and merged

  The unit tests aren't very consistent with regard to testing object
  validity.  Perhaps standardize on $obj->isa("Foo::Bar")?

* DONE [#C] Merge in readme-pod-format branch                           :pod:
  CLOSED: [2011-03-28 Mon 16:07]
  - CLOSING NOTE [2011-03-28 Mon 16:07] \\
    Merged

  Prior to next release, merge in readme-pod-format branch

* DONE [#B] More tests for L::F::H::E                                 :tests:
  CLOSED: [2011-10-24 Mon 16:41]
  - CLOSING NOTE [2011-10-24 Mon 16:41] \\
    Closing task

  Add author-specific tests for Log::Fine::Handle::Email, more
  specifically, email tests that actually generate email via
  Email::Sender::Transport::SMTP or
  Email::Sender::Transport::Sendmail.

  These tests should be enabled via a special environmental variable,
  say, ENABLE_AUTHOR_TESTS

** Task Log

   [2011-10-20 Thu 12:07] New file, t/16-handle-email-smtp.t created
   which generates an email.  Verified working.

* DONE [#B] Figure out what to do with Log::Fine::Handle::File::Timestamp :handle:
  CLOSED: [2011-10-25 Tue 16:48]
  - CLOSING NOTE [2011-10-25 Tue 16:48] \\
    Completed

  Need to figure out what can be done with
  Log::Fine::Handle::File::Timestamp which suffers from two issues:

   1. The filename given is actually a date-stamp rather than a
      time-stamp.

   2. The filename will only change if the DATE changes, but not any
      other values, such as hour or minute.

* DONE [#C] Add method to print out log masks?                        :masks:
  CLOSED: [2011-10-28 Fri 14:11]
  - CLOSING NOTE [2011-10-28 Fri 14:12] \\
    Created new handle method, ~bitmaskListEnabled()~, which will return
    an array (not an array ref) of enabled bitmasks for a given handle.
    Also added associated unit tests.

  Have a method, ~bitmaskListEnabled()~, in Log::Fine::Handle to return
  an array ref of defined logging masks.

  For example:

    #+begin_src perl
    my @currentmasks = @{ $handle->bitmaskListEnabled() };
    #+end_src

  Need to figure out if I'm going to add this to 0.57 or save this
  functionality for 0.58.
* DONE [#C] Add custom templates?                                 :templates:
  CLOSED: [2011-11-22 Tue 10:51]
  - CLOSING NOTE [2011-11-22 Tue 10:52] \\
    Support added as of [[https://github.com/cfuhrman/log-fine/commit/fe15b6105aa9b4ca4f2ae230e43fdaa22a2d27e3][fe15b6105]].  Spiffy!

  Extend L::F::F::Template to allow for custom template keys.
  Ideally, this would work as follows:

  #+BEGIN_SRC perl
  my $counter = 0;

  sub foobar { return ++$counter; } # foobar()

  # define a template formatter with a custom keyword, FOOBAR
  my $template = Log::Fine::Formatter::Template
      ->new(name      => 'template2',
            template  => "[%%TIME%%] %%LEVEL%% (count:%%FOOBAR%%) %%MSG%%\n",
            custom_templates => {
                FOOBAR => \&foobar,                       
            });
  #+END_SRC

** Details:

   1) Should this functionality be added to Template.pm or should
      Template.pm be overridden (L::F::F::Template::Custom)

      I think just adding it to L::F::F::Template would not incur too
      great a penalty

   2) Would there be demand for this functionality?

      Perhaps for custom paging, say, for example, when you're sending
      a page with a dynamic code in the subject line
* DONE [#B] Check for key collision in custom templates           :templates:
  CLOSED: [2011-12-02 Fri 12:51]
  - CLOSING NOTE [2011-12-02 Fri 12:51] \\
    Code in place and unit tests are working properly.  Closing task

  Catch the situation where a user defines two custom templates with
  the same key.  Do not forget to add appropriate unit tests for this.

** Task log

   [2011-12-01 Thu 21:40] Added key collision check and associated
   unit test, although unit test currently generates spewage which
   will need to be filtered.

* DONE [#B] Make sure custom placeholders are stored uppercase    :templates:
  CLOSED: [2011-12-01 Thu 21:42]
  - CLOSING NOTE [2011-12-01 Thu 21:42] \\
    Decided that placeholders are to be stored lowercase instead of
    uppercase.  At any rate, this functionality has been implemented.

  Make sure custom placeholder keys are stored uppercase internally.
  This will make checking for key collisions much easier.

** Task log

   [2011-12-01 Thu 21:41] Decided that placeholders are to be stored
   lowercase instead.

* DONE [#B] Rename Template->_templateValidate()                  :templates:
  CLOSED: [2011-12-02 Fri 12:51]
  - CLOSING NOTE [2011-12-02 Fri 12:52] \\
    Completed.  ~_templateValidate()~ has been replaced with
    ~_placeholderValidate()~

  Rename ~Template->_templateValidate()~ to some other method name
  that has the word 'placeholder' in it.