Greetings, all,
I wrote an interesting reference guide chapter yesterday that has surfaced
a minor design improvement to the system. The chapter is called Extension
Point Definition Files. Take a quick look:
<http://hackydev.ics.hawaii.edu/hackyDevSite/external/docbook/ch12.html>
What's kind of neat about this chapter is that it brings together in one
short chapter the collection of ways in which Hackystat can be
programmatically extended by developers. For the savvy developer trying to
grok Hackystat, this is quite useful.
The first thing to notice is that there's quite a few listed: 9 so far, and
that does not count any of the application level extension points (such as
those in CGQM, PRI, and SDSA). So, we probably have around a dozen
extension points in the current system (including, of course, the ability
to define new extension points through module addition, which I guess is a
meta-extension point :-)
What I discovered from writing the chapter is that in Hackystat:
(a) Extension points should be specified using an XML file.
(b) These files should be uniquely named.
(c) The current system uses a mish-mash of three different file naming
conventions for the known extension point definition files.
So, my design improvement proposal is to standardize the file naming
convention for extension point definition files. I think this will improve
the readability and robustness of the system (by reducing the odds of name
conflicts). It will also help elevate "extension point" to a first class
design construct in the system, which will help future developers to build
enhancements that are more modular and maintainable.
My proposed convention is that all extension point definition files are
named as follows:
<moduleName>.<extensionName>.<extensionType>.def.xml
Applying this convention yields the following file name changes:
command.listsensordata.xml ->
hackyCore_Common.listsensordata.command.def.xml
sdt.activity.xml -> hackySdt_Activity.activity.sdt.def.xml
dailyanalysis.filemetric.xml ->
hackySdt_FileMetric.activity.dailyanalysis.def.xml
dailyprojectdata.size.xml ->
hackySdt_FileMetric.size.dailyprojectdata.def.xml
installer.ant.xml -> hackySensor_Ant.ant.sensor.def.xml
telemetry.filemetric.xml ->
hackySdt_FileMetric.filemetric.telemetry.def.xml
sensor.ant.xml -> hackySensor_Ant.ant.sensor.def.xml
local.build.xml -> hackyCore_Kernel.local.build.def.xml
hackyCore_Build.newmodule.def.docbook.xml ->
hackyCore_Build.newmodule.docbook.def.xml
With this naming scheme, all extension point files must end with the common
suffix of .def.xml. This is important to simplify life for new module
developers who need to create their own application-specific XML
files---right now, if they happen to define an XML file that starts with
"sensor.", the build system will think it's a sensor definition file and
break down. With this convention, we just document that ".def.xml" is a
reserved suffix for extension point definition files and that simple rule
takes care of clashes for all modules.
To see the type of extension point, you look at the last three components
(command.def.xml, sdt.def.xml, dailyanalysis.def.xml, etc.) The prefix
always tells you the module where the definition file came from.
Let me know what you think. I think the renaming should be pretty simple
to carry out, and I volunteer to do it.
Cheers,
Philip
