Re: [ecf-dev] IRC improvements

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Christoph,

Christoph Schwering wrote:
> Hi,
>
> > 1) Modified/improved the IRC provider so that the connect() calls on (to
> > both container and to channel/chat room container) block until
> > completion or failure...as they should according to IContainer.connect()
> > semantics.  IRC has a somewhat weird "double response" structure...to
> > connect and then authenticate...probably because IRC had no
> > authentication initially.  So now it behaves like xmpp and others in
> > terms of timing.
>
> I think with "double response structure" that after calling connect()
> a registration-event is fired.

Yes.  What happens is that onRegistration is called (upon successful 
login/auth), and onError(433) seems to be called if authentication fails 
(bad password, for example...of course there are other errors). 

So what I do is have the thread that calls IContainer.connect() wait 
(with reasonable timeout) until it gets the onRegistration notification 
(via thread in irclib) or onError followed by onDisconnect (as not all 
errors from IRC server mean that connect failed).  When the waiting 
thread gets notified via onRegistration, any IContainer listeners are 
notified with the IContainerConnectedEvent.

This seems to be working fine.

> I don't know much about ECF's API yet, so I can't estimate the effect
> of your changes.
> Just for your information: between calling connect() and receiving the
> registration-event, the IRC server might complain that the chosen
> nickname is already in use and ask the connecting user to choose a new
> one. Therefore, between connect() and receiving the
> registration-event, user-interaction might be useful.

Hmm.  Not sure how to fit this in...well, it could very well use the 
IConnectContext callbacks passed into 
IContainer.connect(target,connectContext).  Actually, that fits rather 
nicely.

For the moment, though, I think probably the IContainer.connect can just 
throw a ContainerConnectException and the (eventual) connectWizard UI 
can retry.

> > 3) Question for group:  Is there a way in IRC to send someone else
> > (either an individual or a group) an arbitrary-length byte array (and
> > not have it appear as a text message)?
>
> As far as I know there is no way in IRC to do so. You can only send
> textmessages to users and/or groups, and these text messages are also
> displayed.
>
> The only exception I know is CTCP. CTCP uses standard messages where
> the message itself has a special format. These messages are not
> displayed by most IRC clients but answered automatically instead.
> CTCP allows to ask other clients for their program name or the local
> time, for example. Additionally, CTCP is used to initiate a DCC
> connection (which is used to send files to each other or chat directly
> with each other).
> CTCP (same like DCC) is not a standard and is not implemented by
> IRClib by the way.
>
> What should the command for sending byte arrays exactly be for? (If
> you mean file transfer, as alread said, this can be done via DCC.)

Well, it could be used for file transfer, or sending objects via the ECF 
datashare or sharedobject APIs for representing things like workbench 
events, resources, workbench config, etc.

Chris how does CTCP do this on IRC?  I'm not sure this is worth the 
trouble (given that irclib doesn't implement it), but I'm just sort of 
curious.

Thanks,

Scott