NAME

Anton Mari Zachary B. Elep

EMAIL

PROJECT TITLE

SendPage Enhancements

SYNOPSIS

This project aims to implement certain enhancements to the
SendPage program (http://sendpage.org) and to update software
packages of this program on the Debian GNU/Linux distribution and
derivatives.

BENEFITS TO THE OSDL COMMUNITY

The Open Source Development Labs (OSDL) has been using SendPage
for its infrastructure event reporting, and being such, it is
imperative that the SendPage program code be as clean and as
well-understood as possible, while keeping the program's execution
highly responsive (or as responsive as it was.) Hence, this
project aims to meet those objectives to make SendPage a better
and more reliable tool for OSDL's developers to use.

Furthermore, because the SendPage program and modules have
distributable packages in the Debian GNU/Linux distribution and
its derivatives, the program can be (and has been) used outside of
the OSDL by others; it is necessary, therefore, to keep those
packages as up-to-date as possible with the latest program
release.

DELIVERABLES

This project improves the SendPage tool in the following ways:

- by reimplementing it to follow a cleaner and better
object-oriented design methodology;

- by implementing the immediate and wanted feature requests as
specified in SendPage's TODO list, to be made possible by the
restructuring of the code as hinted above;

- by completing and polishing the POD documentation accompanying
the SendPage tool and its modules; and

- by updating the sendpage package in Debian GNU/Linux and
derivatives to the latest upstream version (this version
produced under the Summer of Code).

In addition, this project also aims to complete the missing
documentation listed in the TODO list, namely the sendpage-manual
and API.

PROJECT DETAILS

Scope:

This project deals with cleaning up the SendPage implementation to
allow for implementation of wanted feature requests, and the
updating of the current SendPage packages in Debian.

Design:

Code Improvements:

The SendPage program and its accompanying modules should follow a
better object-oriented design methodology with emphasis on
hash-by-name initialization and message-passing, allowing for a
cleaner and better-understood implementation of the code. The
SendPage::Modem module, for example, currently uses a rather
verbose function parameter initialization that, while perfectly
working, detriments to further extension and improvements on the
code.

An interesting possibility to simplify the program code would be
to use Perl's object tying and overloading facilities. By hiding
much of the data (e.g. configuration) as values in a hash that is
actually tied to an object, we can use simpler functions to work
the program.

Documentation Improvements:

Much of SendPage's documentation is incomplete. Like much of
Perl code, documentation should be included in the source code
itself, and should be as clear and easy to understand as
possible.

Debian Packaging:

The current sendpage package in the Debian GNU/Linux archive
requires updating. It seems that the Debian maintainer, Preston
Smith, has been missing in action as of late. Furthermore, there
are at lease 5 outstanding bugs as of this writing that can
easily be resolved.

Implementation Plan:

Code Improvements:

- Rewrite the submodule code to make full use of Perl's
object-oriented facilities, and provide a clean interface by
using ties and overloading operators.

- Change the configuration mechanism so that it follows the new
OO code.

Documentation Improvements:

- Complete the existing documentation, and update it to reflect
changes to the code.

- Start writing the documentation on the DB and DBI schema

Debian Packaging:

- Update the Debian SendPage (and most likely,
Device::SerialPort) packages, including build system and
reported bugs.

Outstanding Issues:

- Some of the feature requests in the TODO need sharpening, and
therefore also need their own separate specifications.

PROJECT SCHEDULE

Assuming that N is the day this project proposal is approved for
implementation, here is an approximate and tentative project
schedule, based on the 4-month (approximately 120-day) timeline
alloted for the Summer of Code:

day N: Start of planning and research

day N + 15: Begin writing initial specifications; brainstorming
with mentor; presentation of draft specs and
documentation

day N + 40: End of planning; final detailed specs of each module
and applications presented; coding, system
documentation and test plan formulation begins once
approved by mentor

day N + 60: End of coding; First testing cycle begins

day N + 90: Documentation and final test plans are refined; Second
testing cycle begins

day N + 120: Release with the mentor's blessings ;-)

By default, status reports are presented to the mentor every week,
with special reports given on each milestone above, as well for
each milestone in the overall timeline for the Summer of Code.

BIO

I am better known as `Zak B. Elep' (or even `Zakame') in most FOSS
circles; in real life, I am currently a sophomore taking up
Associate in Arts at the University of the Philippines - Open
University (http://www.upou.org) since 2005. I have been using
various Free and Open Source Softwares since 1998, and got to use
my first GNU/Linux distribution (Debian, http://www.debian.org) in
late 2003. I am now an active member of the Ubuntu project (see
https://wiki.ubuntu.com/ZakElep) as part of the Masters of the
Universe (MOTU) who maintain the Universe and Multiverse software
components of the distribution.

I am also involved in the Debian project as an active maintainer
for several packages; I am also currently undergoing the Debian
New Maintainer process (https://nm.debian.org) .

I got wind of SendPage primarily through the Google Summer of
Code, and I am particularly interested in it as a Perl project
that needs a lot of developer love. I have been using Perl on and
off as a tool for various tasks since my early years, and I would
like to exercise my knowledge of it to further improve SendPage,
as well as to learn a lot of things from the program.