gnu-social/plugins/Realtime
Mikael Nordfeldth 414a95a784 Initial move towards microformats2
No validation has been attempted yet. Lots of changes left. This
is visibly not (very) different from the previous CSS layout. But
some simplifications have been made.

Might cause issues with local changes to themes and CSS. Also maybe
javascript which depends on certain legacy microformats elements.

The move to microformats2 is motivated by the announcement that all
microformats should be migrated to version 2, as of 2014-06-20 at:
http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2
2014-06-22 17:11:04 +02:00
..
actions plugins onAutoload now only overloads if necessary (extlibs etc.) 2013-08-28 16:10:30 +02:00
classes Replace common_good_random with common_random_hexstr 2013-10-21 13:20:30 +02:00
css Preparing plugins for no-minify-in-core-policy 2014-02-24 01:01:34 +01:00
js Initial move towards microformats2 2014-06-22 17:11:04 +02:00
locale Localisation updates from http://translatewiki.net. 2012-06-30 11:10:38 +00:00
scripts plugins onAutoload now only overloads if necessary (extlibs etc.) 2013-08-28 16:10:30 +02:00
Makefile Makefile for Realtime's min.js 2011-03-01 15:33:10 -08:00
README Realtime plugin: fix i18n, thumbnails, location display, OStatus server display, micro-apps display. 2011-03-14 13:29:35 -07:00
RealtimePlugin.php getConversationUrl introduced for linking to conversations 2014-05-01 15:25:19 +02:00

README

As of StatusNet 1.0.x, actual formatting of the notices is done server-side,
loaded by AJAX after the real-time notification comes in. This has the drawback
that we may make extra HTTP requests and delay incoming notices a little, but
means that formatting and internationalization is consistent.

== TODO ==
* Update mark behaviour (on notice send)
* Pause, Send a notice ~ should not update counter
* Pause ~ retain up to 50-100 most recent notices
* Make it work for Conversation page (perhaps a little tricky)
* IE is updating the counter in document title all the time (Not sure if this
  is still an issue)
* Reconsider the timestamp approach