event.xsd - to extend, or not to extend

8 messages

event.xsd - to extend, or not to extend

Reply Threaded

Chaps,

I'm working on events to send to a new daemon. I have a number of
parameters to add to the event. They will be specific to the daemon
and will be a variety of different types (Integer, String, Date etc.).

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?

Cheers ... J

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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

Antonio Russo

Re: event.xsd - to extend, or not to extend

Reply Threaded

Jonathan,
I had the same trouble. Someone suggested me that only general
parameter should be added to the event
as a property. Otherwise is better to use the Parms.
For example, I have added in the trunk (1.7.x) ifindex to the event
object so when I parse the varbind in trapd I look for ifindex OID and
save it for the event if exists!

Hope this experience will help you!

Regards

Antonio

Il giorno 18/mag/09, alle ore 22:24, jonathan sartin ha scritto:

> Chaps,
>
> I'm working on events to send to a new daemon. I have a number of
> parameters to add to the event. They will be specific to the daemon
> and will be a variety of different types (Integer, String, Date etc.).
>
> 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?
>
> Cheers ... J
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> 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

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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

jonathan sartin

Re: event.xsd - to extend, or not to extend

Reply Threaded

On 18 May 2009, at 21:37, Antonio Russo wrote:

> Jonathan,
> I had the same trouble. Someone suggested me that only general
> parameter should be added to the event
> as a property. Otherwise is better to use the Parms.
> For example, I have added in the trunk (1.7.x) ifindex to the event
> object so when I parse the varbind in trapd I look for ifindex OID and
> save it for the event if exists!

Hi Antonio,

Nice to hear from you. Hope all is well in Italy.

The arguments that I want to add to the event are not related to
network devices, but instead instruct the new deamon to run report
code against the database. They're argument to the report, such as the
period for the report, the format, etc.

I see there's separate alarm and ticket types in event.xsd, and I
wondered if that was the way to go for my daemon.

Cheers ... Jonathan.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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

David Hustace

Re: event.xsd - to extend, or not to extend

Reply Threaded

In reply to this post by jonathan sartin

Some javascript/style in this post has been disabled (why?)

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.

David Hustace
President, The OpenNMS Group, Inc.

------------------------------------------------------------------------------
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

jonathan sartin

Re: event.xsd - to extend, or not to extend

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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.

jonathan sartin

Re: event.xsd - to extend, or not to extend

Reply Threaded

On 29 May 2009, at 22:46, jonathan sartin wrote some stuff......

So I'm bashing my head against a brick wall here. Let me explain what
I'm trying to do. I want to send a message from the webapp to a daemon
that contains an arbitrary number of key value pairs with different
value types (string, long, date etc.). I think want o preserve type
information between sending and receiving because the values are typed
in the model I'm using in the webapp and my deamon will be expecting
particular types.

Of course, I can convert to a string, put the string in an event parm,
and convert it back to the right type in the daemon. But this seems
inelegant. Is there another way of passing these key-value pairs from
the webapp to the daemon?

Cheers ... J

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
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

jonathan sartin

Re: event.xsd - to extend, or not to extend

Reply Threaded

On 2 Jun 2009, at 22:57, jonathan sartin wrote:

>
> On 29 May 2009, at 22:46, jonathan sartin wrote some stuff......
>
> So I'm bashing my head against a brick wall here.

Never mind, I figured out an alternative ;-)

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
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

David Hustace

Re: event.xsd - to extend, or not to extend

Reply Threaded

On Jun 4, 2009, at 2:55 PM, jonathan sartin wrote:

>
> On 2 Jun 2009, at 22:57, jonathan sartin wrote:
>
>>
>> On 29 May 2009, at 22:46, jonathan sartin wrote some stuff......
>>
>> So I'm bashing my head against a brick wall here.
>
> Never mind, I figured out an alternative ;-)

Cool. Sorry I didn't keep up with the discussion. I think perhaps a
restful service is what you might be needing?

David

David Hustace
President
The OpenNMS Group, Inc.

"Every program attempts to expand until it can read mail. Those
programs which cannot so expand are replaced by ones which can."

http://www.jwz.org/

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
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