Eclipse Community Forums: Eclipse SmartHome

Help

Home

Home » Archived » Eclipse SmartHome » Inbox concept

Show: Today's Messages :: Show Polls :: Message Navigator

Inbox concept [message #1641585]

Sat, 28 February 2015 17:34

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

I'm wondering if the inbox concept is intended just for use with new devices/things, or if it can be extended for other purposes.

I think it would be interesting to use it for 'admin' level notifications - eg if a thing goes offline, or something happens that the binding wants to notify the administrator.

As an example, in zwave, I would like to use this to flag that a device is offline - the binding could call an 'add to inbox' method, with a type or level parameters, and receive an ID in response that could later be used for cancelling the notification.

I know this probably overlaps with other notification concepts that may be planned, but I think it would be useful to have this sort of persistent admin alert inbox...

Chris

Report message to a moderator

Re: Inbox concept [message #1643665 is a reply to message #1641585]

Sun, 01 March 2015 17:59

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Hi Chris,

I don´t think that the inbox should be used for other purposes, than for findings things. Actually the whole concept and API is about finding and adding devices. If you use the inbox for notifications, what would happen, if someone wants to "approve" the entry? At the the moment the framework automatically calls the binding with a "createThing" call, which does not make sense. For example the Paper UI integrated the inbox inside the "Setup Wizard" for new devices. Moreover the DiscoveryService concept is hardly wired to the inbox concept, which again is about discovering things.

But the planned notification concept would definitely be the right place for any kind of notifications. The notification concept should have something like an "read/unread" status, so that the user interfaces can show only unread notifications and the user can cancel the notification. So it is similar to the inbox, in a way that it also tracks a list of notifications, that are persisted and can be accessed and not only an event mechanism.

Dennis

Report message to a moderator

Re: Inbox concept [message #1643709 is a reply to message #1643665]

Sun, 01 March 2015 18:25

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

Hi Dennis,
Thanks - that sounds fine - at the end of the day, two lists, or one list with multiple tags seems largely the same to me, so that's fine.

Is there a roadmap of when this is likely to be implemented? I'm not sure of the direction or priorities so it's difficult to know how/where/if I can help.

Cheers
Chris

Report message to a moderator

Re: Inbox concept [message #1644981 is a reply to message #1643709]

Mon, 02 March 2015 09:12

Kai Kreuzer

Messages: 673
Registered: December 2011

Senior Member

This is a good point Chris - you are right that the current Inbox and a future "Notification-Box" have pretty similar requirements - especially as we are now also about to add a TTL or an entry removal possibility for the Inbox.
But adding general notifications to the existing inbox might involve a bit too much refactoring of the existing code. So I would tend to agree with Dennis that we probably rather introduce a separate service for this.

Regarding roadmap: This is very difficult to say. As it is never clear, which resources are available to work on topics and what their own priorities are, it is not really possible to provide something like a project plan of schedule. I tried to start a rough list of topics for a roadmap here: https://wiki.eclipse.org/EclipseSmartHome/Roadmap. Other requirements are usually managed in Bugzilla, for the notifications see e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=434010
Personally, I prefer to concentrate on finishing other things first before starting such big new topics - and at the moment we still have many questions and bugs around the things and the way how to structure bindings, so this is my priority.

Regards,
Kai

Report message to a moderator

Re: Inbox concept [message #1645815 is a reply to message #1644981]

Mon, 02 March 2015 18:05

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Kai, now I´m not sure if we have the same concept in mind, when we talk about the "Notification concept", especially when I read the bug.

For me the notification concept is something where different kinds of messages can be aggregated and stored. These messages may have a TTL, a severity, actions, "read" flag and so on. For example the framework can automatically create a notification, if a new thing is put into the inbox. It is comparable to the android notification concept for example. So it is a litte bit similar to the existing inbox, but only because it stores some entries, that must be acknowledged by the user. Maybe the interface "Inbox" is a bit confusing, it should better be "ThingInbox", but at least from the package "org.eclipse.smarthome.config.discovery" it can be seen that is for discovering things and not a general inbox for messages.

The notification concept, which is mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=434010 is more about how notifications/messages are transported and visualized to the user. I´m not sure if this is the same concept. Of course they belong somehow together. But I would assume that this is another SPI, where different implementation can be used (E-Mail, Android Push Cloud, Twitter etc.). In contrast the "NotificationInbox", which stores messages has only one implementation.

Regards

Dennis

[Updated on: Mon, 02 March 2015 18:06]

Report message to a moderator

Re: Inbox concept [message #1645910 is a reply to message #1645815]

Mon, 02 March 2015 19:11

Kai Kreuzer

Messages: 673
Registered: December 2011

Senior Member

Dennis, you are absolutely right. Having multiple publication channels for notification is definitely a different requirement which asks for its own implementation.

Report message to a moderator

Previous Topic:	handleCommand, handleUpdate and updateState
Next Topic:	"Received update for non-existing item" after .items is read and parsed

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 12:27:08 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter