On 27 May 2009, at 13:54, David Hustace wrote:
On May 18, 2009, at 4:24 PM, jonathan sartin wrote:
Should I put them into the existing Parms (which seem kind of SNMP
specific), or should I extend add a new element to the schema to deal
with them?
Jonathan,
Definitely use Parms for these are key value pairs that the daemon
will understand. The formal Event fields should not be changed for
a specific daemon's purpose.
OK, I can do that. I do have some questions as to why though....
My thinking went along the lines that I could get properly typed
objects unmarshalled from the event without having to encode them some
other way. I'd assumed that any deamon not listening for my event
would just ignore the new elements in the event XML.
The use case is that I want to send a daemon an event to command it to
run a report. The report might take a bunch of parms including
strings, dates and numeric fields.
If I want to send it a date, for example, I'll get the date, convert
it to a string or base64 encode it. I then send the event, with an
Parm key and value pair for the date, get it unmarshalled, and convert
it back. I can do that without too much difficulty, but my thinking
was that castor could do that for me, hence the idea to create
additional parms to hold string, dateTime, long etc. I guess I'm just
curious as to why we want to avoid that. I'm sure there's a good
reason (I can think of several, I just don't know if they're
definitive).
If I want to be explicit with the parm, and add a type attribute, I'll
need to modify Parm anyway or don't we bother with the type attribute?
Thanks .... Jonathan.
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
