Re: [opennms-devel] event.xsd - to extend, or not to extend
jonathan sartin <[email protected]> Fri, 29 May 2009 22:46:06 +0100
| Newsgroups | gmane.network.opennms.bugs,gmane.network.opennms.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============6606234159333023052== Content-Type: multipart/alternative; boundary=Apple-Mail-54--961606103 --Apple-Mail-54--961606103 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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. --Apple-Mail-54--961606103 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><br><div><div>On 27 May 2009, = at 13:54, David Hustace wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><br><div><div>On May 18, 2009, = at 4:24 PM, jonathan sartin wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: -webkit-monospace; font-size: 11px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = auto; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0; ">Should I put them into the = existing Parms (which seem kind of SNMP <br>specific), or should I = extend add a new element to the schema to deal <br>with = them?<br></span></blockquote><br></div><div>Jonathan,</div><div><br></div>= <div>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.</div></div></blockquote></div><br><div>OK, = I can do that. I do have some questions as to why = though....</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><div>Thanks .... = Jonathan.</div></body></html>= --Apple-Mail-54--961606103-- --===============6606234159333023052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ 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 --===============6606234159333023052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============6606234159333023052==--