[Owncloud] idea : Notification system

[Jan-Christoph Borchardt]

Just dropping in quickly:

Apps should not be able to just push notifications about anything to
people. Otherwise it will get really annoying pretty fast.
We have to curate the notifications at some level, and offering a
free-for-all notification framework seems a bit like »we do it just
because we can«. For each app, there are either none, one or just a
few things that are relevant.



On Wed, Jun 6, 2012 at 3:10 PM, Florian Hülsmann <fh at cbix.de> wrote:
> Ok guys, yesterday I pushed some further commits to the user_notifications
> branch that gives us the following features:
>
>  * apps can send (translatable) notifications to users by calling
> OCP\Util::sendUserNotification
>  * as a useful example users get notified when someone shares a file to them
> (see apps/files_sharing/lib_share.php)
>  * the number of unread notifications is displayed in web UI
>  * ... as well as in the document title
>  * drop down list of notification in web UI
>  * apps can tell us to mark a notification as read by calling
> OCP\Util::setUserNotificationRead
>  * basic ajax functionality existing (see OC.notify object in JS) including:
> auto refresh unread notifications, mark as read/unread ... but missing
> buttons etc. in web UI
>  * user notifications as RSS or Atom feed (with HTTP basic auth) using the
> following URLs:
>  ** http://host/owncloud/remote.php/notify_feed/feed.atom
>  ** http://host/owncloud/remote.php/notify_feed/feed.rss
>
> Things that are gonna be changed:
>  * notification icon ;)
>  * notification CSS
>  * more efficient db table (using integer keys instead of strings, because
> notification text is often the same)
>  * add email notifications (and somehow xmpp??)
>  * functions in web UI, such as "mark all notifications as read", delete,
> toggle auto refresh
>  * smart system for changing notifications (e.g. change "1 user commented on
> your gallery" to "2 users commented on your gallery")
>  * group notifications (how to handle "read" flag then?)
>  * use different RSS/ATOM library (...that supports UTF-8 and HTML
> contents!) - sorry, was too lazy to find a better one ;) maybe Zend_Feed,
> which is awesome, but I'm not sure about other ZF dependencies...
>  * real time web UI notifications (kinda impossible with PHP, huh? maybe
> using PubSubHubbub with atom feed...)
>
> ...IMO this should be done before merging with master :)
>
> All in all this is a really useful feature that I'm definitively be gonna
> use in future apps!
>
> Florian
>
> Am 04.06.2012 19:48, schrieb Michael Gapczynski:
>
>> On Monday, June 04, 2012 07:18:43 PM Florian Hülsmann wrote:
>>>
>>> My idea is to use existing OC libs and provide hooks for notifications.
>>> Using these hooks we could send the notifications via email, xmpp etc. or
>>> let 3rd party apps extend the functionalities, e.g. with SMS
>>> notification!
>>>
>>> I was just wondering if the "search" folder will stay in the ownCloud
>>> root
>>> directory and if it's a good idea to have the notify stuff organized the
>>> same way (see user_notifications branch)...
>>>
>>
>> This should be in the apps folder and not the root folder. I don't see an
>> entire app being written just to extend the notifications to another
>> service.
>> So, I don't think you should emit any hooks, but rather keep everything
>> internal.
>>
>> I agree with you that it should be organized like the searching in
>> ownCloud
>> with providers. However, these providers files should be included directly
>> inside your notify app. I think it would also be worthwhile if your app
>> could
>> allow the user to configure how he gets to be notified, i.e. via email or
>> SMS.
>>
>>
>> Michael
>
>
> --
> Florian Hülsmann
> <fh at cbix.de>
> http://cbix.de
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud