I actually don't think it will affect the NotificationMessage* APIs because a NotificationMessage can have multiple Elements in its message content section. If you look at the NotificationMessage API, it has getter methods to iterate over and select the Elements in the payload section. So, the publish() method is actually the part that is inconsistent with the spec and the consumer APIs; since publish() is just taking your content and putting it in a NotificationMessage object, it should be possible to add multiple elements.
That said, what's done is done, and we can't get rid of the publish() methods we already have. I'm slightly concerned about API bloat, but not enough to disagree if multiple users want it. I just wanted to see if any of the other users/developers had an opinion before I added the code. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 02/16/2007 12:54:58 PM: > Hehe, sorry about this new request, Dan. The array idea just came up > recently after stumbling upon the issue. > > I think it's a bit more difficult to implement this new update since it > involves updates to both server and client classes. In particular, this > will affect NotificationMessageListener and NotificationMessage, both of > which currently assume a single Element value. > > The easiest way around this is for developers to just wrap their array > in a single Element, and publish using the existing API. We'd have to > create a serializer to distribute to the client so that they can > deserialize the Element and extract the array. But, that's no different > than what we do now for operations, where we have to create serializers > for custom types. So I'm not sure what's the best approach. > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Friday, February 16, 2007 7:47 AM > To: [email protected] > Subject: RE: publish array of Elements > > I suppose this will also require us to make array versions of the other > publish() methods (for XmlSerializable and Object), which would make six > publish() methods. Like the last API addition, I'm going to let this sit > for 24 hours and let people chime in with their pros/cons. If no one > cares, I'll do it this weekend. > > Dan > > > > "Rosberg Mattias" <[EMAIL PROTECTED]> wrote on 02/16/2007 > 07:59:02 AM: > > > I think it's a great idea. > > > > If you have a situation where you like to publish information that is > sampled > > with very high frequency in your device it could save a lot of > performance if > > you can buffer the samples and send them in an array (timestamped) > with > some > > interval, say every 10 seconds or so. > > > > An array of Elements will also result in less bandwidth usage since > the > > overhead in the SOAP message will be the same if you send one sample > or > a thousand. > > > > -----Original Message----- > > From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] > > Sent: Fri 2/16/2007 2:16 AM > > To: [email protected] > > Subject: publish array of Elements > > > > Currently, NotificationProducer.publish() sends out a single Element. > > Out of curiousity, would it make sense to enhance it to publish an > array > > of Elements? A workaround is to wrap the array in a parent Element, > and > > publish the parent. But I'm trying to see if anyone else has a reason > > to publish an array of elements. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
