[jitsi-dev] Working on IRC support for Jitsi

Danny_van_Heumen · 2013-11-10 21:39:17 UTC

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

Emil_Ivov1 · 2013-11-10 23:37:13 UTC

Hey Danny,

IRC is something we've longed missed in Jitsi, so it's great to know that
someone is working on it.

Before we start discussing the details however, there is one important
point that needs to be taken into account: one of the main reasons we
decides to remove the previous IRC bundle was the fact that pircbot was
distributed under GPL. While it does improve many of its other
deficiencies, pircbotx obviouy can't deal with this one so its license is
the same.

It would hence be great to consider another library with a less viral
license. This actuay means pretty much any other FLOSS license.

Would you be willing to look into this?

Cheers,
Emil

--sent from my mobile

···

On 10 Nov 2013 22:39, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Marc_Laporte · 2013-11-11 14:25:50 UTC

I enthusiastically volunteer as a tester (and will find others!)

Thanks!

···

On Sun, Nov 10, 2013 at 4:39 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Marc Laporte

http://MarcLaporte.com
http://Tiki.org/MarcLaporte
http://AvanTech.net

Yana_Stamcheva · 2013-11-18 13:04:17 UTC

Hey Danny,

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

I believe the problem you experienced is in the case of the processChatRoomHighlight() method calling the processKeyword() method you are talking about. It seems to work fine for an XMPP group chat. Could you please tell us what is the value of "processedMessage", "contentType" and the "keyword" parameters in your case?

When you say "if the user name happens to appear inside an attribute", what attribute do you mean? Could you please give an example?

Thanks,
Yana

···

On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Danny_van_Heumen · 2013-11-11 10:00:29 UTC

Hi Emil,

Okay, so that is (one of) the reason(s) why IRC support was dropped. I
assume you already looked at the "plug-in is not actually
including/changing" stuff about the actual scope of GPL in this case.

I'll have a look at some of the other options, although I am afraid that it
is going to cost us in terms of modern library, wide protocol support, etc.
That's okay though if it is (hopefully) a small cost.

Danny

···

On Mon, Nov 11, 2013 at 12:37 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Danny,

IRC is something we've longed missed in Jitsi, so it's great to know that
someone is working on it.

Before we start discussing the details however, there is one important
point that needs to be taken into account: one of the main reasons we
decides to remove the previous IRC bundle was the fact that pircbot was
distributed under GPL. While it does improve many of its other
deficiencies, pircbotx obviouy can't deal with this one so its license is
the same.

It would hence be great to consider another library with a less viral
license. This actuay means pretty much any other FLOSS license.

Would you be willing to look into this?

Cheers,
Emil

--sent from my mobile
On 10 Nov 2013 22:39, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Danny_van_Heumen · 2013-11-11 18:29:47 UTC

Hi Marc,

I will most likely need one once the implementation has advanced far
enough. It's been a while since I've been a hard-core IRC user, so I can
use an extra pair of eyes for the advanced IRC features

Danny

···

On 11/11/2013 03:25 PM, Marc Laporte wrote:

I enthusiastically volunteer as a tester (and will find others!)

Thanks!

On Sun, Nov 10, 2013 at 4:39 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Yana_Stamcheva · 2013-11-18 13:18:19 UTC

Hey again,

Hey Danny,

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

I believe the problem you experienced is in the case of the processChatRoomHighlight() method calling the processKeyword() method you are talking about. It seems to work fine for an XMPP group chat. Could you please tell us what is the value of "processedMessage", "contentType" and the "keyword" parameters in your case?

When you say "if the user name happens to appear inside an attribute", what attribute do you mean? Could you please give an example?

Actually I've managed to reproduce the issue! You're right. I think passing the plain text IRC message and nothing else would fix it, but then I think we use the same method for parsing history and there we would need to highlight every occurrence of the nickname in the whole conversation..I'll have to take a closer look to the code. If you've already made some tests or have any ideas don't hesitate to share.

Cheers,
Yana

···

On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:

On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Thanks,
Yana

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Emil_Ivov1 · 2013-11-11 11:19:46 UTC

Hi Emil,

Okay, so that is (one of) the reason(s) why IRC support was dropped. I
assume you already looked at the "plug-in is not actually
including/changing" stuff about the actual scope of GPL in this case.

I am not sure I understand what you mean.

I'll have a look at some of the other options, although I am afraid that it
is going to cost us in terms of modern library, wide protocol support, etc.
That's okay though if it is (hopefully) a small cost.

Didn't get this either. Are you saying that no other FLOSS java lib
has a proper IRC implementation?

Emil

···

On Mon, Nov 11, 2013 at 11:00 AM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Danny

On Mon, Nov 11, 2013 at 12:37 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Danny,

IRC is something we've longed missed in Jitsi, so it's great to know that
someone is working on it.

Before we start discussing the details however, there is one important
point that needs to be taken into account: one of the main reasons we
decides to remove the previous IRC bundle was the fact that pircbot was
distributed under GPL. While it does improve many of its other deficiencies,
pircbotx obviouy can't deal with this one so its license is the same.

It would hence be great to consider another library with a less viral
license. This actuay means pretty much any other FLOSS license.

Would you be willing to look into this?

Cheers,
Emil

--sent from my mobile

On 10 Nov 2013 22:39, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

Danny_van_Heumen · 2013-11-18 14:59:01 UTC

Hi Yana,

I can provide an example "before" and "after" value, so you'll see what
happens. IRC's plain text message get wrapped by quite a lot of xml data of
which I am not quite sure that it should have been added at that point. I
do not have an opportunity right now to provide this information. I'll
follow up when I do.

Thanks you for looking into this.

Danny

···

On Mon, Nov 18, 2013 at 2:18 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hey again,

On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:

> Hey Danny,
>
> On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> > wrote:
>
>> Hi all,
>>
>> I have been using Jitsi for a bit now and I really like it. I'd like to
>> help out a bit so I've been looking into IRC support for Jitsi and been
>> trying some things out. I'd like your feedback w.r.t. this effort.
>> Anything that I should look out for, hints, heads up for developing
>> changes (maybe around Multi User Chat support) or whatever comes to
mind.
>>
>> I have been playing around with the code a bit before posting this
>> message because I wanted to familiarize with the code base before
>> actually "announcing" anything. If it turns out that the approach is
>> going the wrong way, that would be too bad, but basically my own gamble

>>
>> So, the current state:
>> - IRC library: I found a few candidates but the one that seemed both
>> fairly recent and modern is PircBotX
>> (http://code.google.com/p/pircbotx/). The way to use this library is
>> very different from the original PircBot, though. A version 2.0 was
>> recently released so my code is based around this version.
>> - Code: I started by adapting the code currently in the repository from
>> the old IRC implementation. IrcStack.java is more or less stripped and
>> I'm rebuilding step by step.
>> - State of operation: It is now possible to connect to a chatroom and
>> see the conversation happening and respond (also notification w.r.t.
>> join/part/quit events). Basically everything thereafter does not work
>> yet, so: no special roles for Ops, etc; no private messages, no mode
>> changes, bans, kicks, whatever...
>>
>> Additionally I have a few questions, and I'd like to know how you think
>> about that:
>> 1. Typical usage of the Multi User Chat code retrieves all the chatrooms
>> upon opening the 'Go to chat room'-window. I don't think many IRC
>> servers will be happy if we do a LIST-request every time this window is
>> openend. So, how would we solve this? (Maybe a trigger when the dropdown
>> box button, the one with the down-arrow, is clicked. Or maybe load one
>> list and cache it or ...)
>> 2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
>> This method seems to try to highlight keywords and for the current
>> chat windows in particular the name of the local users. It replaces
>> every occurence though, breaking the complete xml-structure if the user
>> name happens to appear inside an attribute. I wanted to fix it, but I'm
>> not quite sure what the right solution is: should this method not get
>> passed the complete xml-structured message but only the plaintext actual
>> message from IRC or should it be sensitive to the keyword occurrence
>> within the xml?
>
> I believe the problem you experienced is in the case of the
processChatRoomHighlight() method calling the processKeyword() method you
are talking about. It seems to work fine for an XMPP group chat. Could you
please tell us what is the value of "processedMessage", "contentType" and
the "keyword" parameters in your case?
>
> When you say "if the user name happens to appear inside an attribute",
what attribute do you mean? Could you please give an example?

Actually I've managed to reproduce the issue! You're right. I think
passing the plain text IRC message and nothing else would fix it, but then
I think we use the same method for parsing history and there we would need
to highlight every occurrence of the nickname in the whole
conversation..I'll have to take a closer look to the code. If you've
already made some tests or have any ideas don't hesitate to share.

Cheers,
Yana

>
> Thanks,
> Yana
>
>>
>> So ... any thoughts, remarks?
>> Thanks!
>>
>> Danny
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Danny_van_Heumen · 2013-11-18 23:04:10 UTC

Hi Yana,

I've attached a screenshot of the result when I encounter the issue I
described.This only seems to happen because the message-sending user has a
user name that is very similar to the message-receiving user's.

The message as it enters *processKeyword()*:
<table width="100%" name="table" style="background-color:#efefef;"><tr><td
align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a
style="color:#488fe7;font-weight:bold;text-decoration:none;"
href="dvheumen_">dvheumen_<cite id='13848145477501994503190-editedAt'>
</cite></a></h2></td><td align="right"><h2>Nov 18, 2013
23:42:27</h2></td></tr></table><div id='message13848145477501994503190'
name = 'dvheumen_' date="2013-11-18T23:42:27.750+0100" original_message =
'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>

And the message as it leaves *processKeyword()*:
<table width="100%" name="table" style="background-color:#efefef;"><tr><td
align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a
style="color:#488fe7;font-weight:bold;text-decoration:none;"
href="</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_"></PLAINTEXT><b>dvheumen</b><PLAINTEXT>_<cite
id='13848145477501994503190-editedAt'> </cite></a></h2></td><td
align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div
id='message13848145477501994503190' name =
'</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_'
date="2013-11-18T23:42:27.750+0100" original_message = 'hi'
style=""><PLAINTEXT>hi</PLAINTEXT></div>

As you can see, even within the href-attribute everything is boldly cut off
in order to add the '<b>' and '</b>' tags. I do not think this should be
the case.
Also, this problem only exists in the conversation window. When opening the
window again, the "historic" conversation shows as normal.

For these reasons, my own guess would be to only feed the plain text into
the processKeyword-method, however you people have a better understanding
of the code, I might be overlooking some use case.

Danny

···

On Mon, Nov 18, 2013 at 2:18 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hey again,

On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:

> Hey Danny,
>
> On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> > wrote:
>
>> Hi all,
>>
>> I have been using Jitsi for a bit now and I really like it. I'd like to
>> help out a bit so I've been looking into IRC support for Jitsi and been
>> trying some things out. I'd like your feedback w.r.t. this effort.
>> Anything that I should look out for, hints, heads up for developing
>> changes (maybe around Multi User Chat support) or whatever comes to
mind.
>>
>> I have been playing around with the code a bit before posting this
>> message because I wanted to familiarize with the code base before
>> actually "announcing" anything. If it turns out that the approach is
>> going the wrong way, that would be too bad, but basically my own gamble

>>
>> So, the current state:
>> - IRC library: I found a few candidates but the one that seemed both
>> fairly recent and modern is PircBotX
>> (http://code.google.com/p/pircbotx/). The way to use this library is
>> very different from the original PircBot, though. A version 2.0 was
>> recently released so my code is based around this version.
>> - Code: I started by adapting the code currently in the repository from
>> the old IRC implementation. IrcStack.java is more or less stripped and
>> I'm rebuilding step by step.
>> - State of operation: It is now possible to connect to a chatroom and
>> see the conversation happening and respond (also notification w.r.t.
>> join/part/quit events). Basically everything thereafter does not work
>> yet, so: no special roles for Ops, etc; no private messages, no mode
>> changes, bans, kicks, whatever...
>>
>> Additionally I have a few questions, and I'd like to know how you think
>> about that:
>> 1. Typical usage of the Multi User Chat code retrieves all the chatrooms
>> upon opening the 'Go to chat room'-window. I don't think many IRC
>> servers will be happy if we do a LIST-request every time this window is
>> openend. So, how would we solve this? (Maybe a trigger when the dropdown
>> box button, the one with the down-arrow, is clicked. Or maybe load one
>> list and cache it or ...)
>> 2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
>> This method seems to try to highlight keywords and for the current
>> chat windows in particular the name of the local users. It replaces
>> every occurence though, breaking the complete xml-structure if the user
>> name happens to appear inside an attribute. I wanted to fix it, but I'm
>> not quite sure what the right solution is: should this method not get
>> passed the complete xml-structured message but only the plaintext actual
>> message from IRC or should it be sensitive to the keyword occurrence
>> within the xml?
>
> I believe the problem you experienced is in the case of the
processChatRoomHighlight() method calling the processKeyword() method you
are talking about. It seems to work fine for an XMPP group chat. Could you
please tell us what is the value of "processedMessage", "contentType" and
the "keyword" parameters in your case?
>
> When you say "if the user name happens to appear inside an attribute",
what attribute do you mean? Could you please give an example?

Actually I've managed to reproduce the issue! You're right. I think
passing the plain text IRC message and nothing else would fix it, but then
I think we use the same method for parsing history and there we would need
to highlight every occurrence of the nickname in the whole
conversation..I'll have to take a closer look to the code. If you've
already made some tests or have any ideas don't hesitate to share.

Cheers,
Yana

>
> Thanks,
> Yana
>
>>
>> So ... any thoughts, remarks?
>> Thanks!
>>
>> Danny
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Danny_van_Heumen · 2013-11-11 18:28:14 UTC

Hi Emil,

What I meant to say:
Is the GPL license really a problem? I know this may be kind of a grey
area, but the IRC code is isolated to a specific bundle. Does the GPL
actually become a problem for the whole application? I think this is
related to the whole discussion between static linking and dynamic
linking for shared objects/DLLs. Even if so, I can understand if you
simply don't want to include any GPL-led code in the installer and don't
want to ship a separate bundle/installer for IRC support.
Anyways, I was just wondering about how viral GPL really is in this case.

As for the second point. When I looked, it seemed that this library was
the most feature-rich implementation that I could find. Anyways, I'm
going to have a second look to see what options I can find.

I'll let you know when I've found some interesting options.

Danny

···

On 11/11/2013 12:19 PM, Emil Ivov wrote:

On Mon, Nov 11, 2013 at 11:00 AM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

Hi Emil,

Okay, so that is (one of) the reason(s) why IRC support was dropped. I
assume you already looked at the "plug-in is not actually
including/changing" stuff about the actual scope of GPL in this case.

I am not sure I understand what you mean.

I'll have a look at some of the other options, although I am afraid that it
is going to cost us in terms of modern library, wide protocol support, etc.
That's okay though if it is (hopefully) a small cost.

Didn't get this either. Are you saying that no other FLOSS java lib
has a proper IRC implementation?

Emil

Danny

On Mon, Nov 11, 2013 at 12:37 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Danny,

IRC is something we've longed missed in Jitsi, so it's great to know that
someone is working on it.

Before we start discussing the details however, there is one important
point that needs to be taken into account: one of the main reasons we
decides to remove the previous IRC bundle was the fact that pircbot was
distributed under GPL. While it does improve many of its other deficiencies,
pircbotx obviouy can't deal with this one so its license is the same.

It would hence be great to consider another library with a less viral
license. This actuay means pretty much any other FLOSS license.

Would you be willing to look into this?

Cheers,
Emil

--sent from my mobile

On 10 Nov 2013 22:39, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Foss · 2013-11-19 09:07:46 UTC

Nothing useful here feel free to skip. Danny, this is just a motivational post to let you know how excited I am for Jitsi to maybe again support IRC. Can’t wait to help testing this

···

Am 19.11.2013 um 00:04 schrieb Danny van Heumen <danny@dannyvanheumen.nl>:

Hi Yana,

I've attached a screenshot of the result when I encounter the issue I described.This only seems to happen because the message-sending user has a user name that is very similar to the message-receiving user's.

The message as it enters processKeyword():
<table width="100%" name="table" style="background-color:#efefef;"><tr><td align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a style="color:#488fe7;font-weight:bold;text-decoration:none;" href="dvheumen_">dvheumen_<cite id='13848145477501994503190-editedAt'> </cite></a></h2></td><td align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div id='message13848145477501994503190' name = 'dvheumen_' date="2013-11-18T23:42:27.750+0100" original_message = 'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>

And the message as it leaves processKeyword():
<table width="100%" name="table" style="background-color:#efefef;"><tr><td align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a style="color:#488fe7;font-weight:bold;text-decoration:none;" href="</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_"></PLAINTEXT><b>dvheumen</b><PLAINTEXT>_<cite id='13848145477501994503190-editedAt'> </cite></a></h2></td><td align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div id='message13848145477501994503190' name = '</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_' date="2013-11-18T23:42:27.750+0100" original_message = 'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>

As you can see, even within the href-attribute everything is boldly cut off in order to add the '<b>' and '</b>' tags. I do not think this should be the case.
Also, this problem only exists in the conversation window. When opening the window again, the "historic" conversation shows as normal.

For these reasons, my own guess would be to only feed the plain text into the processKeyword-method, however you people have a better understanding of the code, I might be overlooking some use case.

Danny

On Mon, Nov 18, 2013 at 2:18 PM, Yana Stamcheva <yana@jitsi.org> wrote:
Hey again,

On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:

> Hey Danny,
>
> On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> wrote:
>
>> Hi all,
>>
>> I have been using Jitsi for a bit now and I really like it. I'd like to
>> help out a bit so I've been looking into IRC support for Jitsi and been
>> trying some things out. I'd like your feedback w.r.t. this effort.
>> Anything that I should look out for, hints, heads up for developing
>> changes (maybe around Multi User Chat support) or whatever comes to mind.
>>
>> I have been playing around with the code a bit before posting this
>> message because I wanted to familiarize with the code base before
>> actually "announcing" anything. If it turns out that the approach is
>> going the wrong way, that would be too bad, but basically my own gamble
>>
>> So, the current state:
>> - IRC library: I found a few candidates but the one that seemed both
>> fairly recent and modern is PircBotX
>> (http://code.google.com/p/pircbotx/). The way to use this library is
>> very different from the original PircBot, though. A version 2.0 was
>> recently released so my code is based around this version.
>> - Code: I started by adapting the code currently in the repository from
>> the old IRC implementation. IrcStack.java is more or less stripped and
>> I'm rebuilding step by step.
>> - State of operation: It is now possible to connect to a chatroom and
>> see the conversation happening and respond (also notification w.r.t.
>> join/part/quit events). Basically everything thereafter does not work
>> yet, so: no special roles for Ops, etc; no private messages, no mode
>> changes, bans, kicks, whatever...
>>
>> Additionally I have a few questions, and I'd like to know how you think
>> about that:
>> 1. Typical usage of the Multi User Chat code retrieves all the chatrooms
>> upon opening the 'Go to chat room'-window. I don't think many IRC
>> servers will be happy if we do a LIST-request every time this window is
>> openend. So, how would we solve this? (Maybe a trigger when the dropdown
>> box button, the one with the down-arrow, is clicked. Or maybe load one
>> list and cache it or ...)
>> 2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
>> This method seems to try to highlight keywords and for the current
>> chat windows in particular the name of the local users. It replaces
>> every occurence though, breaking the complete xml-structure if the user
>> name happens to appear inside an attribute. I wanted to fix it, but I'm
>> not quite sure what the right solution is: should this method not get
>> passed the complete xml-structured message but only the plaintext actual
>> message from IRC or should it be sensitive to the keyword occurrence
>> within the xml?
>
> I believe the problem you experienced is in the case of the processChatRoomHighlight() method calling the processKeyword() method you are talking about. It seems to work fine for an XMPP group chat. Could you please tell us what is the value of "processedMessage", "contentType" and the "keyword" parameters in your case?
>
> When you say "if the user name happens to appear inside an attribute", what attribute do you mean? Could you please give an example?

Actually I've managed to reproduce the issue! You're right. I think passing the plain text IRC message and nothing else would fix it, but then I think we use the same method for parsing history and there we would need to highlight every occurrence of the nickname in the whole conversation..I'll have to take a closer look to the code. If you've already made some tests or have any ideas don't hesitate to share.

Cheers,
Yana

>
> Thanks,
> Yana
>
>>
>> So ... any thoughts, remarks?
>> Thanks!
>>
>> Danny
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

<screenshot-corrupted-chat-message.png>_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Yana_Stamcheva · 2013-11-19 11:35:22 UTC

Hi Danny,

Hi Yana,

I've attached a screenshot of the result when I encounter the issue I described.This only seems to happen because the message-sending user has a user name that is very similar to the message-receiving user's.

The message as it enters processKeyword():
<table width="100%" name="table" style="background-color:#efefef;"><tr><td align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a style="color:#488fe7;font-weight:bold;text-decoration:none;" href="dvheumen_">dvheumen_<cite id='13848145477501994503190-editedAt'> </cite></a></h2></td><td align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div id='message13848145477501994503190' name = 'dvheumen_' date="2013-11-18T23:42:27.750+0100" original_message = 'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>

And the message as it leaves processKeyword():
<table width="100%" name="table" style="background-color:#efefef;"><tr><td align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a style="color:#488fe7;font-weight:bold;text-decoration:none;" href="</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_"></PLAINTEXT><b>dvheumen</b><PLAINTEXT>_<cite id='13848145477501994503190-editedAt'> </cite></a></h2></td><td align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div id='message13848145477501994503190' name = '</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_' date="2013-11-18T23:42:27.750+0100" original_message = 'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>

As you can see, even within the href-attribute everything is boldly cut off in order to add the '<b>' and '</b>' tags. I do not think this should be the case.
Also, this problem only exists in the conversation window. When opening the window again, the "historic" conversation shows as normal.

For these reasons, my own guess would be to only feed the plain text into the processKeyword-method, however you people have a better understanding of the code, I might be overlooking some use case.

I agree. Do you already have a fix that works for you? Would you be able to send a patch for this one so that we could test on our side?

Cheers,
Yana

···

On 19 Nov 2013, at 00:04, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Danny

On Mon, Nov 18, 2013 at 2:18 PM, Yana Stamcheva <yana@jitsi.org> wrote:
Hey again,

On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:

> Hey Danny,
>
> On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> wrote:
>
>> Hi all,
>>
>> I have been using Jitsi for a bit now and I really like it. I'd like to
>> help out a bit so I've been looking into IRC support for Jitsi and been
>> trying some things out. I'd like your feedback w.r.t. this effort.
>> Anything that I should look out for, hints, heads up for developing
>> changes (maybe around Multi User Chat support) or whatever comes to mind.
>>
>> I have been playing around with the code a bit before posting this
>> message because I wanted to familiarize with the code base before
>> actually "announcing" anything. If it turns out that the approach is
>> going the wrong way, that would be too bad, but basically my own gamble
>>
>> So, the current state:
>> - IRC library: I found a few candidates but the one that seemed both
>> fairly recent and modern is PircBotX
>> (http://code.google.com/p/pircbotx/). The way to use this library is
>> very different from the original PircBot, though. A version 2.0 was
>> recently released so my code is based around this version.
>> - Code: I started by adapting the code currently in the repository from
>> the old IRC implementation. IrcStack.java is more or less stripped and
>> I'm rebuilding step by step.
>> - State of operation: It is now possible to connect to a chatroom and
>> see the conversation happening and respond (also notification w.r.t.
>> join/part/quit events). Basically everything thereafter does not work
>> yet, so: no special roles for Ops, etc; no private messages, no mode
>> changes, bans, kicks, whatever...
>>
>> Additionally I have a few questions, and I'd like to know how you think
>> about that:
>> 1. Typical usage of the Multi User Chat code retrieves all the chatrooms
>> upon opening the 'Go to chat room'-window. I don't think many IRC
>> servers will be happy if we do a LIST-request every time this window is
>> openend. So, how would we solve this? (Maybe a trigger when the dropdown
>> box button, the one with the down-arrow, is clicked. Or maybe load one
>> list and cache it or ...)
>> 2. For ChatConversationPanel.processKeyword(message, contentType, keyword):
>> This method seems to try to highlight keywords and for the current
>> chat windows in particular the name of the local users. It replaces
>> every occurence though, breaking the complete xml-structure if the user
>> name happens to appear inside an attribute. I wanted to fix it, but I'm
>> not quite sure what the right solution is: should this method not get
>> passed the complete xml-structured message but only the plaintext actual
>> message from IRC or should it be sensitive to the keyword occurrence
>> within the xml?
>
> I believe the problem you experienced is in the case of the processChatRoomHighlight() method calling the processKeyword() method you are talking about. It seems to work fine for an XMPP group chat. Could you please tell us what is the value of "processedMessage", "contentType" and the "keyword" parameters in your case?
>
> When you say "if the user name happens to appear inside an attribute", what attribute do you mean? Could you please give an example?

Actually I've managed to reproduce the issue! You're right. I think passing the plain text IRC message and nothing else would fix it, but then I think we use the same method for parsing history and there we would need to highlight every occurrence of the nickname in the whole conversation..I'll have to take a closer look to the code. If you've already made some tests or have any ideas don't hesitate to share.

Cheers,
Yana

>
> Thanks,
> Yana
>
>>
>> So ... any thoughts, remarks?
>> Thanks!
>>
>> Danny
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

<screenshot-corrupted-chat-message.png>_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Emil_Ivov1 · 2013-11-11 18:35:08 UTC

Hey Danny,

Hi Emil,

What I meant to say:
Is the GPL license really a problem? I know this may be kind of a grey
area, but the IRC code is isolated to a specific bundle. Does the GPL
actually become a problem for the whole application?

IANAL but I believe that as long as they are distributed together yes.
That's the reason why Sun had to include the "Classpath exception" for
Java when they open sourced it under the GPL.

It would work if the plugin was downloaded separately but we don't do
this in Jitsi.

We do make an exception in the case of x264 but only because they
offer commercial licenses so people that want to distribute Jitsi with
proprietary code could either remove x264 or buy licenses for it.

I think this is
related to the whole discussion between static linking and dynamic
linking for shared objects/DLLs. Even if so, I can understand if you
simply don't want to include any GPL-led code in the installer and don't
want to ship a separate bundle/installer for IRC support.
Anyways, I was just wondering about how viral GPL really is in this case.

As for the second point. When I looked, it seemed that this library was
the most feature-rich implementation that I could find. Anyways, I'm
going to have a second look to see what options I can find.

I'll let you know when I've found some interesting options.

Thanks very much! I appreciate you being accommodating! It would be
great if we could make this happen.

Cheers,
Emil

···

On Mon, Nov 11, 2013 at 7:28 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Danny

On 11/11/2013 12:19 PM, Emil Ivov wrote:

On Mon, Nov 11, 2013 at 11:00 AM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:

Hi Emil,

Okay, so that is (one of) the reason(s) why IRC support was dropped. I
assume you already looked at the "plug-in is not actually
including/changing" stuff about the actual scope of GPL in this case.

I am not sure I understand what you mean.

I'll have a look at some of the other options, although I am afraid that it
is going to cost us in terms of modern library, wide protocol support, etc.
That's okay though if it is (hopefully) a small cost.

Didn't get this either. Are you saying that no other FLOSS java lib
has a proper IRC implementation?

Emil

Danny

On Mon, Nov 11, 2013 at 12:37 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Danny,

IRC is something we've longed missed in Jitsi, so it's great to know that
someone is working on it.

Before we start discussing the details however, there is one important
point that needs to be taken into account: one of the main reasons we
decides to remove the previous IRC bundle was the fact that pircbot was
distributed under GPL. While it does improve many of its other deficiencies,
pircbotx obviouy can't deal with this one so its license is the same.

It would hence be great to consider another library with a less viral
license. This actuay means pretty much any other FLOSS license.

Would you be willing to look into this?

Cheers,
Emil

--sent from my mobile

On 10 Nov 2013 22:39, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi all,

I have been using Jitsi for a bit now and I really like it. I'd like to
help out a bit so I've been looking into IRC support for Jitsi and been
trying some things out. I'd like your feedback w.r.t. this effort.
Anything that I should look out for, hints, heads up for developing
changes (maybe around Multi User Chat support) or whatever comes to mind.

I have been playing around with the code a bit before posting this
message because I wanted to familiarize with the code base before
actually "announcing" anything. If it turns out that the approach is
going the wrong way, that would be too bad, but basically my own gamble

So, the current state:
- IRC library: I found a few candidates but the one that seemed both
fairly recent and modern is PircBotX
(http://code.google.com/p/pircbotx/). The way to use this library is
very different from the original PircBot, though. A version 2.0 was
recently released so my code is based around this version.
- Code: I started by adapting the code currently in the repository from
the old IRC implementation. IrcStack.java is more or less stripped and
I'm rebuilding step by step.
- State of operation: It is now possible to connect to a chatroom and
see the conversation happening and respond (also notification w.r.t.
join/part/quit events). Basically everything thereafter does not work
yet, so: no special roles for Ops, etc; no private messages, no mode
changes, bans, kicks, whatever...

Additionally I have a few questions, and I'd like to know how you think
about that:
1. Typical usage of the Multi User Chat code retrieves all the chatrooms
upon opening the 'Go to chat room'-window. I don't think many IRC
servers will be happy if we do a LIST-request every time this window is
openend. So, how would we solve this? (Maybe a trigger when the dropdown
box button, the one with the down-arrow, is clicked. Or maybe load one
list and cache it or ...)
2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
This method seems to try to highlight keywords and for the current
chat windows in particular the name of the local users. It replaces
every occurence though, breaking the complete xml-structure if the user
name happens to appear inside an attribute. I wanted to fix it, but I'm
not quite sure what the right solution is: should this method not get
passed the complete xml-structured message but only the plaintext actual
message from IRC or should it be sensitive to the keyword occurrence
within the xml?

So ... any thoughts, remarks?
Thanks!

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

Danny_van_Heumen · 2013-11-19 19:35:48 UTC

···

Hey Foss,

  Thanks for letting me know.

  The plan for now (which is totally subject to change and complete

unguaranteed :P) is to make a (stable) basic implementation that
can be used for just chatting. Get that out and see where we go
from there.

  Danny

  On 11/19/2013 10:07 AM, Foss wrote:

  Nothing useful here feel free to skip. Danny, this is just a
motivational post to let you know how excited I am for Jitsi to
maybe again support IRC. Can’t wait to help testing this

Am 19.11.2013 um 00:04 schrieb Danny van Heumen danny@dannyvanheumen.nl:

Hi Yana,

                  I've attached a screenshot of the result when I
encounter the issue I described.This only seems to
happen because the message-sending user has a user
name that is very similar to the message-receiving
user’s.

The message as it enters processKeyword():
                <table width="100%" name="table"
style=“background-color:#efefef;”>

dvheumen_

Nov 18, 2013
23:42:27
hi

And the message as it leaves processKeyword():
              <table width="100%" name="table"
style=“background-color:#efefef;”>

dvheumen_

Nov 18, 2013
23:42:27
<div id='message13848145477501994503190' name = 'dvheumen_' date="2013-11-18T23:42:27.750+0100" original_message = 'hi' style="">hi

              As you can see, even within the href-attribute
everything is boldly cut off in order to add the
‘’ and ‘’ tags. I do not think this
should be the case.
              Also, this problem only exists in the conversation
window. When opening the window again, the “historic”
conversation shows as normal.

              For these reasons, my own guess would be to
only feed the plain text into the
processKeyword-method, however you people have a
better understanding of the code, I might be
overlooking some use case.

Danny

            On Mon, Nov 18, 2013 at 2:18 PM,

Yana Stamcheva yana@jitsi.org wrote:

Hey again,

                  On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org                      >

wrote:

                  > Hey Danny,

                  >

                  > On 10 Nov 2013, at 22:39, Danny van Heumen

<danny@dannyvanheumen.nl >
wrote:

                  >

                  >> Hi all,

                  >>

                  >> I have been using Jitsi for a bit now and

I really like it. I’d like to

                  >> help out a bit so I've been looking into

IRC support for Jitsi and been

                  >> trying some things out. I'd like your

feedback w.r.t. this effort.

                  >> Anything that I should look out for,

hints, heads up for developing

                  >> changes (maybe around Multi User Chat

support) or whatever comes to mind.

                  >>

                  >> I have been playing around with the code

a bit before posting this

                  >> message because I wanted to familiarize

with the code base before

                  >> actually "announcing" anything. If it

turns out that the approach is

                  >> going the wrong way, that would be too

bad, but basically my own gamble

                  >>

                  >> So, the current state:

                  >> - IRC library: I found a few candidates

but the one that seemed both

                  >> fairly recent and modern is PircBotX

                  >> ([http://code.google.com/p/pircbotx/](http://code.google.com/p/pircbotx/)                      ).

The way to use this library is

                  >> very different from the original PircBot,

though. A version 2.0 was

                  >> recently released so my code is based

around this version.

                  >> - Code: I started by adapting the code

currently in the repository from

                  >> the old IRC implementation. IrcStack.java

is more or less stripped and

                  >> I'm rebuilding step by step.

                  >> - State of operation: It is now possible

to connect to a chatroom and

                  >> see the conversation happening and

respond (also notification w.r.t.

                  >> join/part/quit events). Basically

everything thereafter does not work

                  >> yet, so: no special roles for Ops, etc;

no private messages, no mode

                  >> changes, bans, kicks, whatever...

                  >>

                  >> Additionally I have a few questions, and

I’d like to know how you think

                  >> about that:

                  >> 1. Typical usage of the Multi User Chat

code retrieves all the chatrooms

                  >> upon opening the 'Go to chat

room’-window. I don’t think many IRC

                  >> servers will be happy if we do a

LIST-request every time this window is

                  >> openend. So, how would we solve this?

(Maybe a trigger when the dropdown

                  >> box button, the one with the down-arrow,

is clicked. Or maybe load one

                  >> list and cache it or ...)

                  >> 2. For

ChatConversationPanel.processKeyword(message,
contentType, keyword):

                  >>   This method seems to try to highlight

keywords and for the current

                  >> chat windows in particular the name of

the local users. It replaces

                  >> every occurence though, breaking the

complete xml-structure if the user

                  >> name happens to appear inside an

attribute. I wanted to fix it, but I’m

                  >> not quite sure what the right solution

is: should this method not get

                  >> passed the complete xml-structured

message but only the plaintext actual

                  >> message from IRC or should it be

sensitive to the keyword occurrence

                  >> within the xml?

                  >

                  > I believe the problem you experienced is in

the case of the processChatRoomHighlight() method
calling the processKeyword() method you are
talking about. It seems to work fine for an XMPP
group chat. Could you please tell us what is the
value of “processedMessage”, “contentType” and the
“keyword” parameters in your case?

                  >

                  > When you say "if the user name happens to

appear inside an attribute", what attribute do you
mean? Could you please give an example?

              Actually I've managed to reproduce the issue! You're

right. I think passing the plain text IRC message and
nothing else would fix it, but then I think we use the
same method for parsing history and there we would
need to highlight every occurrence of the nickname in
the whole conversation…I’ll have to take a closer
look to the code. If you’ve already made some tests or
have any ideas don’t hesitate to share.

              Cheers,

              Yana


                  >

                  > Thanks,

                  > Yana

                  >

                  >>

                  >> So ... any thoughts, remarks?

                  >> Thanks!

                  >>

                  >> Danny

                  >>

                  >>

                  >> dev mailing list

                  >> dev@jitsi.org

                  >> Unsubscribe instructions and other list

options:

                  >> [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

                  >





                  _______________________________________________

                  dev mailing list

                  dev@jitsi.org

                  Unsubscribe instructions and other list options:

                  [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

<screenshot-corrupted-chat-message.png>_______________________________________________
        dev mailing list

        dev@jitsi.org

        Unsubscribe instructions and other list options:


_______________________________________________
dev mailing list
Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev dev@jitsi.org http://lists.jitsi.org/mailman/listinfo/dev

Danny_van_Heumen · 2013-11-20 09:51:24 UTC

Hey Yana,

I have not fixed the problem yet. Up to now it was enough to know that
sending messages worked. I will be looking into this pretty soon, I guess.

Danny

···

On Tue, Nov 19, 2013 at 12:35 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Danny,

On 19 Nov 2013, at 00:04, Danny van Heumen <danny@dannyvanheumen.nl> > wrote:

> Hi Yana,
>
> I've attached a screenshot of the result when I encounter the issue I
described.This only seems to happen because the message-sending user has a
user name that is very similar to the message-receiving user's.
>
> The message as it enters processKeyword():
> <table width="100%" name="table"
style="background-color:#efefef;"><tr><td align="left" ><h2
id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a
style="color:#488fe7;font-weight:bold;text-decoration:none;"
href="dvheumen_">dvheumen_<cite id='13848145477501994503190-editedAt'>
</cite></a></h2></td><td align="right"><h2>Nov 18, 2013
23:42:27</h2></td></tr></table><div id='message13848145477501994503190'
name = 'dvheumen_' date="2013-11-18T23:42:27.750+0100" original_message =
'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>
>
> And the message as it leaves processKeyword():
> <table width="100%" name="table"
style="background-color:#efefef;"><tr><td align="left" ><h2
id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a
style="color:#488fe7;font-weight:bold;text-decoration:none;"
href="</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_"></PLAINTEXT><b>dvheumen</b><PLAINTEXT>_<cite
id='13848145477501994503190-editedAt'> </cite></a></h2></td><td
align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div
id='message13848145477501994503190' name =
'</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_'
date="2013-11-18T23:42:27.750+0100" original_message = 'hi'
style=""><PLAINTEXT>hi</PLAINTEXT></div>
>
> As you can see, even within the href-attribute everything is boldly cut
off in order to add the '<b>' and '</b>' tags. I do not think this should
be the case.
> Also, this problem only exists in the conversation window. When opening
the window again, the "historic" conversation shows as normal.
>
> For these reasons, my own guess would be to only feed the plain text
into the processKeyword-method, however you people have a better
understanding of the code, I might be overlooking some use case.

I agree. Do you already have a fix that works for you? Would you be able
to send a patch for this one so that we could test on our side?

Cheers,
Yana

>
> Danny
>
>
>
> On Mon, Nov 18, 2013 at 2:18 PM, Yana Stamcheva <yana@jitsi.org> wrote:
> Hey again,
>
> On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:
>
> > Hey Danny,
> >
> > On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> > wrote:
> >
> >> Hi all,
> >>
> >> I have been using Jitsi for a bit now and I really like it. I'd like
to
> >> help out a bit so I've been looking into IRC support for Jitsi and
been
> >> trying some things out. I'd like your feedback w.r.t. this effort.
> >> Anything that I should look out for, hints, heads up for developing
> >> changes (maybe around Multi User Chat support) or whatever comes to
mind.
> >>
> >> I have been playing around with the code a bit before posting this
> >> message because I wanted to familiarize with the code base before
> >> actually "announcing" anything. If it turns out that the approach is
> >> going the wrong way, that would be too bad, but basically my own
gamble
> >>
> >> So, the current state:
> >> - IRC library: I found a few candidates but the one that seemed both
> >> fairly recent and modern is PircBotX
> >> (http://code.google.com/p/pircbotx/). The way to use this library is
> >> very different from the original PircBot, though. A version 2.0 was
> >> recently released so my code is based around this version.
> >> - Code: I started by adapting the code currently in the repository
from
> >> the old IRC implementation. IrcStack.java is more or less stripped and
> >> I'm rebuilding step by step.
> >> - State of operation: It is now possible to connect to a chatroom and
> >> see the conversation happening and respond (also notification w.r.t.
> >> join/part/quit events). Basically everything thereafter does not work
> >> yet, so: no special roles for Ops, etc; no private messages, no mode
> >> changes, bans, kicks, whatever...
> >>
> >> Additionally I have a few questions, and I'd like to know how you
think
> >> about that:
> >> 1. Typical usage of the Multi User Chat code retrieves all the
chatrooms
> >> upon opening the 'Go to chat room'-window. I don't think many IRC
> >> servers will be happy if we do a LIST-request every time this window
is
> >> openend. So, how would we solve this? (Maybe a trigger when the
dropdown
> >> box button, the one with the down-arrow, is clicked. Or maybe load one
> >> list and cache it or ...)
> >> 2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
> >> This method seems to try to highlight keywords and for the current
> >> chat windows in particular the name of the local users. It replaces
> >> every occurence though, breaking the complete xml-structure if the
user
> >> name happens to appear inside an attribute. I wanted to fix it, but
I'm
> >> not quite sure what the right solution is: should this method not get
> >> passed the complete xml-structured message but only the plaintext
actual
> >> message from IRC or should it be sensitive to the keyword occurrence
> >> within the xml?
> >
> > I believe the problem you experienced is in the case of the
processChatRoomHighlight() method calling the processKeyword() method you
are talking about. It seems to work fine for an XMPP group chat. Could you
please tell us what is the value of "processedMessage", "contentType" and
the "keyword" parameters in your case?
> >
> > When you say "if the user name happens to appear inside an attribute",
what attribute do you mean? Could you please give an example?
>
> Actually I've managed to reproduce the issue! You're right. I think
passing the plain text IRC message and nothing else would fix it, but then
I think we use the same method for parsing history and there we would need
to highlight every occurrence of the nickname in the whole
conversation..I'll have to take a closer look to the code. If you've
already made some tests or have any ideas don't hesitate to share.
>
> Cheers,
> Yana
>
> >
> > Thanks,
> > Yana
> >
> >>
> >> So ... any thoughts, remarks?
> >> Thanks!
> >>
> >> Danny
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev@jitsi.org
> >> Unsubscribe instructions and other list options:
> >> http://lists.jitsi.org/mailman/listinfo/dev
> >
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
<screenshot-corrupted-chat-message.png>_______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Danny_van_Heumen · 2013-11-21 18:52:11 UTC

Hi Yana,

Could you have a look at this patch?
I had a quick look and it seems that we can just use existing
infrastructure for keyword highlighting. This seems to do the trick for
me, although I did not test it very extensively...

Thanks,
Danny

keyword-highlight-fix.patch (1.97 KB)

···

On 11/19/2013 12:35 PM, Yana Stamcheva wrote:

I agree. Do you already have a fix that works for you? Would you be able to send a patch for this one so that we could test on our side?

Cheers,
Yana

Jungle_Boogie · 2013-11-19 20:05:18 UTC

Hi Danny,

While IRC clients on their own are pretty cool and even clients like irssi
are nice, building this into Jitsi will be fabulous!

Thanks for your efforts to improve Jitsi!

Best,
Jungle

···

On 19 November 2013 11:35, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hey Foss,

Thanks for letting me know.
The plan for now (which is totally subject to change and complete
unguaranteed :P) is to make a (stable) basic implementation that can be
used for just chatting. Get that out and see where we go from there.

Danny

On 11/19/2013 10:07 AM, Foss wrote:

Nothing useful here feel free to skip. Danny, this is just a motivational
post to let you know how excited I am for Jitsi to maybe again support IRC.
Can’t wait to help testing this

Am 19.11.2013 um 00:04 schrieb Danny van Heumen <danny@dannyvanheumen.nl > >:

Hi Yana,

I've attached a screenshot of the result when I encounter the issue I
described.This only seems to happen because the message-sending user has a
user name that is very similar to the message-receiving user's.

The message as it enters *processKeyword()*:
<table width="100%" name="table" style="background-color:#efefef;"><tr><td
align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a
style="color:#488fe7;font-weight:bold;text-decoration:none;"
href="dvheumen_">dvheumen_<cite id='13848145477501994503190-editedAt'>
</cite></a></h2></td><td align="right"><h2>Nov 18, 2013
23:42:27</h2></td></tr></table><div id='message13848145477501994503190'
name = 'dvheumen_' date="2013-11-18T23:42:27.750+0100" original_message =
'hi' style=""><PLAINTEXT>hi</PLAINTEXT></div>

And the message as it leaves *processKeyword()*:
<table width="100%" name="table" style="background-color:#efefef;"><tr><td
align="left" ><h2 id="messageHeader" date='2013-11-18T23:42:27.750+0100'><a
style="color:#488fe7;font-weight:bold;text-decoration:none;"
href="</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_"></PLAINTEXT><b>dvheumen</b><PLAINTEXT>_<cite
id='13848145477501994503190-editedAt'> </cite></a></h2></td><td
align="right"><h2>Nov 18, 2013 23:42:27</h2></td></tr></table><div
id='message13848145477501994503190' name =
'</PLAINTEXT><b>dvheumen</b><PLAINTEXT>_'
date="2013-11-18T23:42:27.750+0100" original_message = 'hi'
style=""><PLAINTEXT>hi</PLAINTEXT></div>

As you can see, even within the href-attribute everything is boldly cut
off in order to add the '<b>' and '</b>' tags. I do not think this should
be the case.
Also, this problem only exists in the conversation window. When opening
the window again, the "historic" conversation shows as normal.

For these reasons, my own guess would be to only feed the plain text
into the processKeyword-method, however you people have a better
understanding of the code, I might be overlooking some use case.

Danny

On Mon, Nov 18, 2013 at 2:18 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hey again,

On 18 Nov 2013, at 14:04, Yana Stamcheva <yana@jitsi.org> wrote:

> Hey Danny,
>
> On 10 Nov 2013, at 22:39, Danny van Heumen <danny@dannyvanheumen.nl> >> wrote:
>
>> Hi all,
>>
>> I have been using Jitsi for a bit now and I really like it. I'd like to
>> help out a bit so I've been looking into IRC support for Jitsi and been
>> trying some things out. I'd like your feedback w.r.t. this effort.
>> Anything that I should look out for, hints, heads up for developing
>> changes (maybe around Multi User Chat support) or whatever comes to
mind.
>>
>> I have been playing around with the code a bit before posting this
>> message because I wanted to familiarize with the code base before
>> actually "announcing" anything. If it turns out that the approach is
>> going the wrong way, that would be too bad, but basically my own
gamble
>>
>> So, the current state:
>> - IRC library: I found a few candidates but the one that seemed both
>> fairly recent and modern is PircBotX
>> (http://code.google.com/p/pircbotx/). The way to use this library is
>> very different from the original PircBot, though. A version 2.0 was
>> recently released so my code is based around this version.
>> - Code: I started by adapting the code currently in the repository from
>> the old IRC implementation. IrcStack.java is more or less stripped and
>> I'm rebuilding step by step.
>> - State of operation: It is now possible to connect to a chatroom and
>> see the conversation happening and respond (also notification w.r.t.
>> join/part/quit events). Basically everything thereafter does not work
>> yet, so: no special roles for Ops, etc; no private messages, no mode
>> changes, bans, kicks, whatever...
>>
>> Additionally I have a few questions, and I'd like to know how you think
>> about that:
>> 1. Typical usage of the Multi User Chat code retrieves all the
chatrooms
>> upon opening the 'Go to chat room'-window. I don't think many IRC
>> servers will be happy if we do a LIST-request every time this window is
>> openend. So, how would we solve this? (Maybe a trigger when the
dropdown
>> box button, the one with the down-arrow, is clicked. Or maybe load one
>> list and cache it or ...)
>> 2. For ChatConversationPanel.processKeyword(message, contentType,
keyword):
>> This method seems to try to highlight keywords and for the current
>> chat windows in particular the name of the local users. It replaces
>> every occurence though, breaking the complete xml-structure if the user
>> name happens to appear inside an attribute. I wanted to fix it, but I'm
>> not quite sure what the right solution is: should this method not get
>> passed the complete xml-structured message but only the plaintext
actual
>> message from IRC or should it be sensitive to the keyword occurrence
>> within the xml?
>
> I believe the problem you experienced is in the case of the
processChatRoomHighlight() method calling the processKeyword() method you
are talking about. It seems to work fine for an XMPP group chat. Could you
please tell us what is the value of "processedMessage", "contentType" and
the "keyword" parameters in your case?
>
> When you say "if the user name happens to appear inside an attribute",
what attribute do you mean? Could you please give an example?

Actually I've managed to reproduce the issue! You're right. I think
passing the plain text IRC message and nothing else would fix it, but then
I think we use the same method for parsing history and there we would need
to highlight every occurrence of the nickname in the whole
conversation..I'll have to take a closer look to the code. If you've
already made some tests or have any ideas don't hesitate to share.

Cheers,
Yana

>
> Thanks,
> Yana
>
>>
>> So ... any thoughts, remarks?
>> Thanks!
>>
>> Danny
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

<screenshot-corrupted-chat-message.png>
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing listdev@jitsi.org
Unsubscribe instructions and other list options:http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si

Yana_Stamcheva · 2013-11-25 12:56:06 UTC

Hi Danny,

I agree. Do you already have a fix that works for you? Would you be able to send a patch for this one so that we could test on our side?

Cheers,
Yana

Hi Yana,

Could you have a look at this patch?
I had a quick look and it seems that we can just use existing
infrastructure for keyword highlighting. This seems to do the trick for
me, although I did not test it very extensively...

Works great for me!

Your patch is now committed and ack-ed.

Thanks,
Yana

···

On 21 Nov 2013, at 19:52, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

On 11/19/2013 12:35 PM, Yana Stamcheva wrote:

Thanks,
Danny
<keyword-highlight-fix.patch>