[Bug 70434] Idle: add IrcCommand extension

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70434

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #11)
> > Are IRC commands guaranteed to be representable in UTF-8, or should we be
> > sending binary? Or should we transcode UTF-8 into the configured server
> > charset like we do for PRIVMSGs?
> 
> The conversion is done from UTF-8 by idle_connection_hton() which is called
> by _send_with_priority(), so using UTF-8 as input is fine here, isn't it?

OK. When I wrote that I was reading the spec, not the implementation:
specifications that don't specify this sort of thing considered harmful :-)

I think this is worth calling out in the spec, maybe something like this:

The command is supplied in UTF-8 (because strings on D-Bus are always UTF-8).
It is transcoded into the connection's configured character set, if different,
before sending to the server.

> > If the user sends a command that does something Telepathy can already do,
> > should Idle do things like spawning a channel and emitting MessageSent as a
> > side-effect? I think the answer should be "yes" but I could be persuaded
> > otherwise. Other possibilities are "remain silent" and "raise an error".
> 
> humm good point. Let's raise an error for now? If there is TP API to do that
> use the TP API.

Raising an error for now seems OK: there can't be any existing code that relies
on particular commands working. Let's spec that 

We should perhaps take the "signal it as if they'd used the right API" approach
for future feature additions.

> > I think this method call should return an opaque string token, and there
> > should be a signal CommandResponse(s Token, s Response) or CommandResponse(s
> > Token, ay Response), depending whether we decide IRC is a text stream or a
> > bytestream. Alternatively, we could wait for the server response, translate
> > it into success-or-error and return it, and advise clients to set a
> > longer-than-default timeout if the command might take a while.
> 
> We are not garanteed to receive a reply so in any case we should have a
> timeout to not keep the token in memory forever.

Reading the IRC RFC again, there's no way to tell how numeric
(server-to-client) responses relate to textual (client-to-server) commands:
commands aren't guaranteed to provoke a response, and responses are only
distinguished by order). If we have this message sequence:

    --> FOO cassidy :here is a thing
    --> BAR #telepathy :whatever
    <-- 481 :Permission Denied- You're not an IRC operator

we can't distinguish between two possibilities: either there was no reply to
the FOO command, and the BAR command got error 481; or the FOO command got
error 481, and there was no reply (yet) to the BAR command.

So, never mind, we can't do this in a machine-readable way at all - the best we
can do is to send arbitrary textual messages to the user (see also Bug #39157,
Bug #26696, and I just opened Bug #70489).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.