Whether to sync after connecting or not is desired depends on the application,
and it's better to remove the possibility of doing so. Having to done one
explicit call to :sync() is not a big deal, and makes the intention of code
using the module clearer. And our code simpler.
The "event_id" returned by the HS is returned directly, instead of
a lone table with a single "event_id" member, for the following methods:
room:send_text()
room:send_emote()
room:send_notice()
This adds an output handler for Busted which reuses the built-in "utfTerminal"
handler, and augments it by showing the name of each suite/test as it is run.
This makes the room:get_alias_or_id() method return the shortest of the room
aliases in case that a canonical_alias is not set. In general this will save
screen real estate when a client uses the method to get a readable room
identifier to display to the user.
This new methods returns the most adequate identifier for a room:
1. If defined, the room's canonical alias.
2. Otherwise, the first alias.
3. As a last resort, the room identifier is returned.
Instead of adding more and more possible conditions on which the while-loop
inside client:sync() could stop, support passing a callback function which is
used to determine when to stop the loop.
The old "so N iterations behaviour" can be achieved with something like:
function iterate_n_times(n)
return function ()
n = n - 1
return n == 0
end
end
client:sync(iterate_n_times(10))
If no function is passed, the client:sync() function loops forever.
This handles the fact that when using the /sync endpoint, events for already
joined rooms are also in the "join" dictionary in the response. The firing of
the "joined" event is moved to client:_make_room() and done only the first
time that the room creation is requested.
This also fixes bogus behavior: previosly, when a message was sent to a room
there would be multiople places where the "joined" event would be fired, and
message events pushed multile times onto the room object, which would call
the event handlers more than once for each message. Ugh.
This neatly allows to pass the room object passed to the "invited" event
directly to :join_room(). This way the user does not need to know that
rooms have a "room_id" attribute.
This allows hooking to both room join and room leave events at the client
level, which apart from being more orthogonal, may be more convenient
sometimes.
The __pairs metamethod was introduced in 5.2, so instead of using pairs()
on http.headers values, use its :each() method — which is what the __pairs
metamethod calls anyway.
When receiving a HTTP response without a statusline, "nil" is returned as
reponse headers and status line values, but the response code will still
be "200 Success", which is quite not right as there wasn't ever a response
status code received. This patch adds a check for a status line, and returns
with an early error if needed.
This condition can be triggered by trying to speak plain HTTP to a
HTTPS-enabled server, e.g. using http://matrix.org:8448 instead of
https://matrix.org:8448 as homeserver URL.
This removes the support for passing values to eventable.functions() and
eventable.object() which are bound to be passed to handlers. On top of
simplifying the code overall, this also avoids having three different
implementations of the fire() function.
In the existing code, the only case in which a handler argument is fixed
is for objects which pass themselves. This use case is covered by
eventable.object(), so the removed code was not realy ever used.