On 15.06.2012 03:26, Florian Hülsmann wrote:
I still love the idea, so I'm adding this to the planned features list:
* let users control which apps can actually send notifications to them
(with block/ignore/allow/limit buttons)
* let apps provide a relevance/importance level (like logging levels in
OC_Log^^)
* let apps provide notification classes, so the user can decide what
kind of notifications of a specific app he/she wants to receive...
Agreed, this three features make a notification system useful. If users
do not have a chance to control notifications it is annoying and not
appreciated. And even if 'we' control which apps notify what I think its
not gonna to work satisfactory.
I made quite some experiences in this space while working on this:
http://en.opensuse.org/openSUSE:Hermes
...but as this is slowly becoming sorta overkill, I'm not sure anymore
if notifications should be integrated in OC core / distribution. Any
opinions?
Correct, to make it well it's a big project. I also doubt it should be
part of the core. But nevertheless it's important and a great addition :-)
regards,
Klaas
Am 15.06.2012 01:26, schrieb 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<f...@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
<f...@cbix.de>
http://cbix.de
_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
