Sadly, I don't have a prediction. I am a software consultant, and last
year was very tough for business. I've been putting all my extra time
into trying to form new business relationships with longer-term
contracts (6 months+ plus). Ideally, a company would like to have some
simple but flexible monitoring like pymon, and they would just contract
with me for something like distributed pymon (see
http://maillists.adytum.us/pipermail/pymon/2006-March/000352.html),
or for detailed reporting (detailed monitoring/service records)
possibly tying in my work with PyRRD, or for adding MIB support, etc.
All of these and more would be wonderful because not only would I be
getting paid for something that I loved and am good at, but all of you
would be reaping the benefits as well, since this would all go back
into the source code.
Once I am not longer working week-to-week, I will have more stability
and more time. At which point, I will continue with the pymon
componentization, unit tests, additional monitors, distributed/peered
pymon, and UI stuff like the shell, improving the web UI, integration
with jabber and email, etc.
None of it is difficult to do, and in most cases I already have
prototypes or proofs-of-concept written. It's a matter of "leisure" and
time...
Also, discussing pymon architecture on the mail list really gets me
going. After I send this email off, I will probably spend the rest of
the night background-processing these thoughts, and when I have a space
hour or two this next week, I could very well write some code -- simply
out of the benefit of this type of interaction. So, if all you have to
give is questions and time, that may be all that is needed in some
cases for me to write additional code for pymone :-)
While I'm thinking about it, here's a few more notes on the componentization:
Each piece of pymon need to have formal tests. Each piece should be
written such that it can be plugged into fake/dummy test setups, and
pass the tests written specifically for that peice. For instance:
monitors. All they are is client factories. But in order to test these,
the unit test suite (twisted.trial) will have to setup the necessary
infrastructure, essentially a "dummy" pymon instance. Ordinarily, that
would be a pain in the ass. But with components, we will be able to do
this clearly and cleanly.
The goal of this isn't just to have unit tests -- it's to have what
unit tests provide: an ideal vehical for debugging complicated
software. If there is a problem in one of the monitors or in the
notification system or in the pymon shell, it will simply be a matter
of looking at an isolated component, or of the communications between
two components. As things stand now, debugging is very difficult due to
a lack of comprehensive unit tests and a sane way of implementing them.
Once this is in place, adding features will be even easier that it is
now. And there will not be an exponential increase in the maintenence
burden. With an increase in components, an increase in maintenence is
simply a linear relationship.
What's more, if I have no time to implement features, the components
and documentation will make it very easy for anyone who wants to
contribute (especially if they already know twisted).
These are the reasons that componentizing pymon is my top priority.
Doing so ensures that you actually get what you want with the pymon
shell, etc.
I know I reambled on, but I hope this is helpful... and not discouraging!
Thanks!
d
P.S. A note about that distributed pymon email link above: In that
email, I mention using XML-RPC for inter-pymon comms. I have since
written a Twisted JSON-RPC server, complete with unit tests. I needed
HTTP Basic Auth, so it's still got some overhead, but less than
XML-RPC. One of the things I'd like to do is supplement my twisted
JSON-RPC library code with a TCP implementation for when authentication
is not needed, so that the option would exists for super-lightwieght
RPC.
If you are interested, here is the code for the twisted JSON-RPC server:
http://projects.adytum.us/tracs/adytum/wiki/TwistedJsonRpc
It has a complete set of unit tests, and all pass. You use it
identically to how you use twisted.web.xmlrpc, with the exception of
replacing XMLRPC with JSONRPC, etc. There is no good jsonrpc library
comparable to xmlrpclib right now, thought Bob Ippoolito has taken the
first step with the latest release of simplejson (he's providing method
hooks now).
As you can see from the length of my email and my P.S., I really do
love this stuff and really wish I could spend more time on it right now
:-)
Please keep the questions and comments coming :-)