[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] Alarm Acknowledgement
Dave, Remember everything can be batched using the Sys.batch operation. Personally I favor an operation directly on the alarm since it is more flexible and keeps the spec simpler. You can still implement it however you want with creative use of URIs for alarms. Brian -----Original Message----- From: Richards, Dave [mailto:drichards@trane.com] Sent: Thursday, March 23, 2006 10:51 AM To: obix-xml@lists.oasis-open.org Subject: RE: [obix-xml] Alarm Acknowledgement Having the operation be against the alarm object itself leaves you unable to do a bulk acknowledgement. You'd have multiple round trips rather than one and I don't know how important that is. The user would not notice any difference unless the network was unusually (or inherently) slow. Also, are there considerations for the implementation of having operations against dynamic/transient objects? A fixed service would seem simpler in some respects. So to answer your question, I have a feeling, but I'm not yet sure what it is. -----Original Message----- From: ahansen@tridium.com [mailto:ahansen@tridium.com] Sent: Thursday, March 16, 2006 3:15 PM To: obix-xml@lists.oasis-open.org Subject: [obix-xml] Alarm Acknowledgement I would like change how oBIX alarms are acknowledged. The specification currently defines an AlarmService (section 15.4) for doing this. The sole purpose of the AlarmService is for acking alarms and the way it is done is by passing the service a list of alarm URI's. Since alarms are required to have URI's and are therefore individually reachable, I don't see the need for the level of indirection the alarm service introduces. Instead, I would like to add an ack operation to the AckAlarm (section 15.2.3) contract. Does anyone have any feelings about this?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]