Community
Participate
Working Groups
IRC CTCP allows peers to exchange connection information so that they can send information (e.g. files) directly between peers. We can use this mechanism, once available in the irclib-based provider, to implement the ECF filetransfer API.
Adding keywords
I'm working on it. In fact, I'm working on a wrapper of IRClib's core. This wrapper is intended to add an abstraction layer that eases client writing. As a part of this, CTCP will be implemented. The latest source is available in IRClib's CVS directory which you can browse here: http://moepii.svn.sourceforge.net/viewvc/moepii/trunk/. The new code is in src/org/schwering/irc/manager and .../manager/event. The code is not yet ready to be used in an application; I'm testing right now with a small test client I'm writing at the moment. When the wrapper seems to be stable so far, I'll implement the CTCP stuff. In total, this shouldn't take too long. I'll post again when the wrapper library has reached stable status.
(In reply to comment #2) > I'm working on it. In fact, I'm working on a wrapper of IRClib's core. This > wrapper is intended to add an abstraction layer that eases client writing. As a > part of this, CTCP will be implemented. > > The latest source is available in IRClib's CVS directory which you can browse > here: http://moepii.svn.sourceforge.net/viewvc/moepii/trunk/. The new code is > in src/org/schwering/irc/manager and .../manager/event. > > The code is not yet ready to be used in an application; I'm testing right now > with a small test client I'm writing at the moment. When the wrapper seems to > be stable so far, I'll implement the CTCP stuff. In total, this shouldn't take > too long. > > I'll post again when the wrapper library has reached stable status. > One way to look at ECF's structure is as a 'wrapper' library for messaging...e.g. presence and chat functionality via presence API for IRC. So although I have no objection to having an abstraction layer for IRCLib, it might be helpful to use and/or extend the ECF abstractions for some creating some clients. Thanks for the update Christoph.
The additional wrapper library ontop of IRClib I talked about earlier is now more or less completed (i.e., it's probably still unstable and there are still minor things to do). This library supports much more sophisticated listeners than IRClib. This results in a larger API, but it should do much work which otherwise would have to be done by the client-programmer. This library also supports CTCP. There's a general problem with IRC and CTCP. The protocol has evolved over many years, therefore the IRC RFC(s) only reflect parts of the reality. The things are even worse with CTCP, because there's not even an RFC. The old IRClib with its small API and philosophy to be very close (concerning the abstraction layer) to the protocol still exists unchanged. The new "wrapper library" tries be a higher level IRC library with as little loss of generality as possible. The current code is in IRClib's SVN repository which can be browsed (http://moepii.sourceforge.net/irclib/javadoc/) or checked out (https://moepii.svn.sourceforge.net/svnroot/moepii/trunk). You can also have a look at the current javadocs which I uploaded temporarily at http://schwering.ath.cx/~chs/irclib/ (the old packages are org.schwering.irc.lib and org.schwering.irc.lib.ssl, the new ones are org.schwering.irc.manager and org.schwering.irc.manager.event). During the next days, I'll probably change some things in the library and test it. Then I'll have a look how to integrate it in ECF, but I'm afraid I won't have much time in the next months to work on ECF's IRC provider.
*** Bug 220264 has been marked as a duplicate of this bug. ***
Resolving as wontfix as no resources available. If contributor or committer resources become available, please reopen.
