[Bug 70434] Idle: add IrcCommand extension

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Oct 14 21:46:55 CEST 2013


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

--- Comment #11 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> ---
> 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?

> I think we need examples, because the conventional client syntax "/badger
> snake" does not actually exist in the IRC protocol (although clients that do
> not understand /badger would frequently interpret it as "/quote badger
> snake" which means "send the literal string 'badger snake' to the server).
> 
> For instance, "MODE #telepathy +s" or "PRIVMSG xclaesse :are you there?"
> might make good examples.

Ok, I'll add examples.

> 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.

> 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.

> @@ +34,5 @@
> > +        <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/>
> > +        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
> > +        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
> > +        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
> > +        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
> 
> When would you get these errors? Disconnected and NetworkError I can see,
> but how do the rest work? Are we expecting the CM to interpret the response?

Leftover from copy pasting, I'll remove it.

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


More information about the telepathy-bugs mailing list