[sendpage-devel] Status Report for Week 2

[Zak B. E. <za...@sp...>]

Status Report for Week 2
========================

Hi all! =)

Here is the second status report for my Summer of Code project for
improving Sendpage.  I'd like to apologize for the lateness of this
report, for it was unavoidably delayed due to a few real-life hits
(see below.)  Nevertheless, even as I have not been able to provide
timely updates, I have been rather hard at work doing the project
offline, and putting notes on it in my newly-acquired notebook
(thanks Google!)

Without further ado, here are the details of what has been done so
far:


Code Improvements
=================

Picking up from where I left off, I have proceeded with continuing
my annotations/modifications to the code in preparation for
restructuring.  I have enforced Kees' suggested coding style in
almost all the library modules, and in doing so I simplified some of
the minor chunks.  I have also enforced using strictures in the
modules; although not all of them are fully strict-compliant yet.


Exploring Alternatives to Object Representations
================================================

The most work that I've done, however, was in reassessing the
current object representation of the modules and in analyzing the
strength of their `objectiveness,' so to speak.  In particular, I
felt rather uneasy about some the modules' behaviors when dealing
with their internal state; it was particularly easy, for example, to
be able to modify Sendpage::Modem's underlying hash representation
from the outside, which IMO may cause side effects later on.

I am aware of Perl's underlying attitude WRT objects--wrap objects
around a warning that says:

   "IN CASE OF FIRE, BREAK GLASS"

However, in this case, accessing an object's underlying
representation (even in the case of object methods) leads to code
that assumes too much about an object's particular implementation,
thus breaking encapsulation.

In response to this, I see a few solutions to help clarify the code:

  - Enforce the use of accessor methods throughout the codebase,
    both for public users and for other methods.  E.g.

      $self->{USER}; 	       becomes 	$self->user();
      $self->{USER} = "name";  becomes	$self->user("name");

    Accessor methods are relatively cheap to make, usually just
    involving a foreach() loop to make new names in the package's
    symbol table, assigning to anonymous subs.

  - Use a closure as the object representation itself.  This leads
    to code that is a little bit more persnickety, but a lot more
    discerning, since the object itself can now implement checks to
    its state upon access and/or modification.

I am already at work in doing the former; see my patches to
Sendpage::Recipient.  I am still looking at the feasibility of the
latter, especially if there are any concerns about speed.


Updating the Debian Packages
============================

Because the Debian (and Ubuntu, et al.) packages of Sendpage (and
Device::SerialPort) are quite out of date, I have contacted their
respective maintainers, Preston Smith (sendpage) and Mike Mattice
(libdevice-serialport-perl) for their information.  I have also
asked them if they are still interested in maintaining these
packages.

As a side note, I noticed that Sendpage and Device::SerialPort both
contain a `./debian' directory in CVS; while I find that myself not
too surprising, Debian has insisted time and again that upstream
sources should not ship a `./debian' in their tarball, since package
maintainers may opt to implement their own package building and/or
patch system that may not be compatible with what upstream currently
has.

Since in this case both Sendpage and Device::SerialPort CVS have
their own `./debian' tree, I suggest that these directories be moved
in their own CVS module, `debian-dir', that can be tracked and
developed separately from the Perl code; e.g. we can have
`debian-dir/sendpage' and `debian-dir/libdevice-serialport-perl'
containing the Debian packaging bits, separate from the module code.


Real Life Hits
--------------

During the past week I experienced my first stumbling block:
hardware failure.  My monitor, which has been exhibiting signs of
power loss in the past months, had finally given way, and I was at a
loss on how to continue my work given that I have no monitor :/
Fortunately, my uncle had a spare, so I was able to get it working
on my system.

Also, there seemed to be a snag regarding my enrollment status at
the school, which effectively rendered me incapable of accessing my
online class portals.  Fortunately this has since been resolved, and
I'm happy to be back in class :D

Unfortunately, another hit is making its way: I will be going to
Manila this weekend to attend my first class session for the
semester, and I expect to be back by Monday next week :/ Hopefully
I'll be back with my very own monitor by then, as well as a couple
or so of unit tests for the Sendpage modules. :D


Next Steps
==========

The delays made by my real-life hits may have tested my patience a
little, but I look forward to completing what I left off:

  - The design spec for Sendpage and the modules
  - Filling out the documentation
  - Updating the Debian packages


__END__

Cheers,

Zakame

-- 
Zak B. Elep  ||  http://zakame.spunge.org
za...@ub...  ||  za...@sp...
1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D