The API was changed slightly so that has_capability now takes the
whole $context object (we almost always have it anyway)
The $kill thing was removed. If you want to assert a capability
then use:
require_capability('capname', $context);
with optional variables to modify the error message
Misc bugs here and there also removed and code tidied
=======================================
WARNING: DEV IS CURRENTLY VERY UNSTABLE.
This is a mega-checkin of the new Roles system. A lot of changes have
been made in core and modules.
Currently there are a lot of rough edges and known problems. We are
working hard on these .. .the reason for getting this into HEAD at this
stage is enable us to move faster (our branch was diverging from HEAD
too much).
Please keep an eye on http://docs.moodle.org/en/Roles for current status
and information for developers on how to use the new Roles system.
Some users reported that mod/chat was silently dropping some messages. The
user's browser may not be able to keep up with the rate at which he submits
chat messages. This update keeps things sane.
Merged from MOODLE_16_STABLE
Author: Donal McMullan <donal@catalyst.net.nz>
This is an alternative version of jsupdate.php that acts
as a long-running daemon. It will feed/stall/feed JS updates
to the client. From the module configuration select "Stream"
updates.
The client connection is not forever though. Once we reach
CHAT_MAX_CLIENT_UPDATES (currently 1000), it will force
the client to re-fetch it.
This buys us all the benefits that chatd has, minus the setup,
as we are using apache to do the daemon handling.
Chat still defaults to the normal update method, which is now
optimised to take advantage of keepalives -- so this change is
safe. The instructions in the config page also indicate that this
mode may not be well supported everywhere. It hasn't been
tested on IIS for starters.
In terms of relative cost -- if each hit on jsupdate.php incurs
on ~20 db queries and delivers one update to the client, each hit
on jsupdate takes ~20 queries, and then roughly 2~3 queries to
serve each of the next 1000 updates. On busy sites, the difference
is huge.
There is still room for enhancements in both keepalive and stream
update methods. I am pretty sure we can trim DB queries more.
User's pane now also uses keepalives -- if the refresh freq is below
the disconnect timeout, then it is a win. Otherwise it wastes memory
at the server end.
By using output buffering, we now support HTTP Keep-Alive, which means
that each client gets tightly bound to a single apache child - this means
that we get
+ lower resource usage on the webserver
+ _much_ lower resource usage on webserver and dbserver if pconnects are used
+ a good case for further caching (memcache/mmcache)
Using ab via localhost or fast LAN using keepalives is actually slower from the
client perspective -- still lighter on the server. Via slower links (DSL/modem)
the responses are faster.
+ we are now more conservative in the fields it asks from the db
+ also more conservative with upates to chat_users
+ messages are now added via POST requests instead of GET
(While I was at it I also turned the autologinguests off for most module pages, except on the index.php pages and the view.php pages for those modules that allow guests)
It's not well tested yet - I'm hoping to do some testing on moodle.org
with some real people and get this refined enough for the Beta release
later today.
