[jitsi-dev] IRC integration

#1

Hey Danny,

I was wondering what the status of the IRC work was. I know that you
have an early version and I think we should look into integrating it
in an incremental way.

We'd need a little help doing this. Could you please start with
individual pull requests on the changes that you've needed to do to
core Jitsi stuff? A short explanation for each one would be most
welcome too.

Does this make sense? Or did you have something in mind?

Emil

···

--
https://jitsi.org

#2

Hi Emil,

The IRC work is kind of on hold for the simple reason that I got held up
for the last 3 weeks or so by something urgent. The last things I was
doing w.r.t. integration were related to:
1. fixing some things related to comments by Ingo.
2. integrating Certificate Service so that we know how TLS connections
behave (not yet upstreamed) This work is okay for a first version, I am
not quite sure, though, how IRC is supposed to work when I connect to
hostname A and one out of 10 servers responds ... obviously the
certificate won't match since it is named B. ... anyways, that's not by
any means a dangerous issue, may reproduce a false negative though
w.r.t. hostname check on TLS connection.
3. I fixed some stuff w.r.t. spurious wake-ups with Object.wait(). That
should be okay now.

Last time I quickly looked at OperationSetPresence, but I need to spend
some decent time exploring that piece of inner workings, because I'm not
quite sure how that functions exactly.

I am all for integrating. I think it would be good if you could have a
quick look at the code to see how much of the core is exactly changed,
since I believe it is not that much. The biggest changes were related to
the IRC wizard UI. (And some stuff I already sent in.)

Danny

···

On 02/18/2014 12:42 PM, Emil Ivov wrote:

Hey Danny,

I was wondering what the status of the IRC work was. I know that you
have an early version and I think we should look into integrating it
in an incremental way.

We'd need a little help doing this. Could you please start with
individual pull requests on the changes that you've needed to do to
core Jitsi stuff? A short explanation for each one would be most
welcome too.

Does this make sense? Or did you have something in mind?

Emil

#3

Oh and also, I made some small unit tests for some of the code that I
wrote, but I didn't really put them in the existing testing framework
yet. I simply replaced 'src' for 'test' in the file location. So let me
know what you want to do with that.

Danny

···

On 02/18/2014 12:42 PM, Emil Ivov wrote:

Hey Danny,

I was wondering what the status of the IRC work was. I know that you
have an early version and I think we should look into integrating it
in an incremental way.

We'd need a little help doing this. Could you please start with
individual pull requests on the changes that you've needed to do to
core Jitsi stuff? A short explanation for each one would be most
welcome too.

Does this make sense? Or did you have something in mind?

Emil

#4

Hi Emil,

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:
- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.
I am not keen on putting if-statements around logging method calls,
since that feels like a level of micro-optimization I am not yet ready
for. So, let me know if you guys want me to, but I prefer to keep it
simple for now.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

Kind regards,
Danny

···

On 02/18/2014 12:42 PM, Emil Ivov wrote:

Hey Danny,

I was wondering what the status of the IRC work was. I know that you
have an early version and I think we should look into integrating it
in an incremental way.

We'd need a little help doing this. Could you please start with
individual pull requests on the changes that you've needed to do to
core Jitsi stuff? A short explanation for each one would be most
welcome too.

Does this make sense? Or did you have something in mind?

Emil

#5

Unless someone else has more time than me, I'll look over it tomorrow
(hopefully, or sometime this week).

Ingo

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Danny

···

-----Original Message-----
van Heumen
Sent: Sonntag, 2. März 2014 21:33
To: Jitsi Developers; Emil Ivov
Subject: Re: [jitsi-dev] IRC integration
Hi Emil,

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:
- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing. I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

Kind regards,
Danny

On 02/18/2014 12:42 PM, Emil Ivov wrote:

Hey Danny,

I was wondering what the status of the IRC work was. I know that you
have an early version and I think we should look into integrating it
in an incremental way.

We'd need a little help doing this. Could you please start with
individual pull requests on the changes that you've needed to do to
core Jitsi stuff? A short explanation for each one would be most
welcome too.

Does this make sense? Or did you have something in mind?

Emil

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

#6

Hi Ingo,

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be desirable.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

Danny

···

On 03/03/2014 11:44 PM, Ingo Bauersachs wrote:

Unless someone else has more time than me, I'll look over it tomorrow
(hopefully, or sometime this week).

Ingo

-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Danny

van Heumen
Sent: Sonntag, 2. M�rz 2014 21:33
To: Jitsi Developers; Emil Ivov
Subject: Re: [jitsi-dev] IRC integration
Hi Emil,

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:
- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing. I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

Kind regards,
Danny

On 02/18/2014 12:42 PM, Emil Ivov wrote:

Hey Danny,

I was wondering what the status of the IRC work was. I know that you
have an early version and I think we should look into integrating it
in an incremental way.

We'd need a little help doing this. Could you please start with
individual pull requests on the changes that you've needed to do to
core Jitsi stuff? A short explanation for each one would be most
welcome too.

Does this make sense? Or did you have something in mind?

Emil

_______________________________________________
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

#7

IMO creating a pull request on github is better because of the convenient
code-review features offered (even if not very advanced). Also, I believe
you can share links to snippets of code which will make review and
discussion easier.

- Sandeep

···

On Mon, Mar 3, 2014 at 3:03 PM, Danny van Heumen <danny@dannyvanheumen.nl>wrote:

Hi Ingo,

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be
desirable.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

Danny

On 03/03/2014 11:44 PM, Ingo Bauersachs wrote:
> Unless someone else has more time than me, I'll look over it tomorrow
> (hopefully, or sometime this week).
>
> Ingo
>
>> -----Original Message-----
>> From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of
> Danny
>> van Heumen
>> Sent: Sonntag, 2. März 2014 21:33
>> To: Jitsi Developers; Emil Ivov
>> Subject: Re: [jitsi-dev] IRC integration
>> Hi Emil,
>>
>> I'm not sure if you read my previous messages as I didn't get a reply
>> (AFAIK) ... doesn't really matter though.
>>
>> Small update: I cleaned up my personal fork which is also in an existing
>> pull request. Currently, the pull request should only contain
>> modifications in the following areas:
>> - config files (classpath, project, build file),
>> - IRC protocol implementation,
>> - IRC reggwiz gui code
>>
>> There should not be any modification to generic Jitsi infrastructure
>> anymore, since almost everything was already provided in separate
>> patches and integrated some time ago and I cleaned up the one remaining
>> thing. I am not keen on putting if-statements around logging method
>> calls, since that feels like a level of micro-optimization I am not yet
>> ready for. So, let me know if you guys want me to, but I prefer to keep
>> it simple for now.
>>
>> So, how do you want to do the big blog-o-change? Are you going to use
>> the pull request, or do you want me to provide the changes in some other
>> way?
>>
>> Kind regards,
>> Danny
>>
>>
>>
>> On 02/18/2014 12:42 PM, Emil Ivov wrote:
>>> Hey Danny,
>>>
>>> I was wondering what the status of the IRC work was. I know that you
>>> have an early version and I think we should look into integrating it
>>> in an incremental way.
>>>
>>> We'd need a little help doing this. Could you please start with
>>> individual pull requests on the changes that you've needed to do to
>>> core Jitsi stuff? A short explanation for each one would be most
>>> welcome too.
>>>
>>> Does this make sense? Or did you have something in mind?
>>>
>>> Emil
>>>
>>
>>
>> _______________________________________________
>> 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

#8

IMO creating a pull request on github is better because of the
convenient code-review features offered (even if not very advanced).
Also, I believe you can share links to snippets of code which will make
review and discussion easier.

I generally agree, but not in this case: one change is so big that GitHub
doesn't show it in the compare view anymore.

- Sandeep

Ingo

#9

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

#10

Hi Ingo,

I need to fix some string literals that are too long and I have done
some extra cleaning up. If there's something else I can take care of,
let me know. I plan on finishing up this weekend and I can give you a
signal (by pull request comment or email) to let you know I am done.

Some more responses below ...

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

Okay.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Right.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

Okay, so I still need to change those literals.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Actually, I meant this for Emil :slight_smile:

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

Yes, I moved back to master once I started preparing for a possible
merge. So just ignore all other branches. They're either old or in
preparation for some larger change.

Pull Request #16 is still valid as it also includes new commits.

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

Right, sure. I was actually referring specifically to still being
experimental. Anyways, I put in a FIXME so I won't forget when I am
finishing up.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

This thing seems to grow with new commits, so yeah.

Kind regards,
Danny

Ingo

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

Danny

···

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

#11

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

···

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

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

#12

Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

···

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

--
Marc Laporte

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

#13

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

···

On 03/25/2014 08:18 PM, Marc Laporte wrote:

Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

#14

Hi Danny!

I hope you are well.

Is there anything new since what is here?
https://github.com/jitsi/jitsi/pull/16

I really really look forward to testing.

Thanks!

···

On Tue, Mar 25, 2014 at 5:26 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

On 03/25/2014 08:18 PM, Marc Laporte wrote:

Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

--
Marc Laporte

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

#15

Hi Marc,

Thanks for your interest. I'm okay, just very busy with personal matters
at the moment.

The pull request is still current. It automatically includes more recent
changes that I've pushed.
Some new(er) additions are:
* Support for opening chat (room) windows for channels that were
automatically joined. (Chat room initiated by the client library instead
of Jitsi.)
* Better support for IRC formatting control codes.
* Popup messages in case joining a channel fails (this is extremely
trivial, but it didn't work)
* And a few small tweaks for consistency, better handling of threading
and events, etc.

For now I need to do some slight tweaks, because of some confusion with
the way chat rooms are handled.
Also, I have contacted the author of the IRC client library and he
responded pretty enthusiastically about including the library in the IRC
implementation for Jitsi. I wanted to be sure he was still supporting
the library, since he was "off the radar" for a bit. He has already
included a few minor fixes, so currently I'm using an unmodified
development snapshot again.

I'm trying to finish up so we have something to merge, but I seem to end
up needing some slight changes here and there. I'm expecting one or two
other ones. After that we should be ready. (There's still a patch for
changes in Jitsi itself that isn't merged yet.)

Kind regards,
Danny

···

On 04/23/2014 12:32 PM, Marc Laporte wrote:

Hi Danny!

I hope you are well.

Is there anything new since what is here?
https://github.com/jitsi/jitsi/pull/16

I really really look forward to testing.

Thanks!

On Tue, Mar 25, 2014 at 5:26 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

On 03/25/2014 08:18 PM, Marc Laporte wrote:

Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen >>> <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

#16

I guess the missing patch is not the isPrivate thing? Otherwise I don't see a pull request open or I just cannot find it. If it was a diff on the list, could you please open a pull request?

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

···

On 23.04.2014, at 21:57, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi Marc,

Thanks for your interest. I'm okay, just very busy with personal matters
at the moment.

The pull request is still current. It automatically includes more recent
changes that I've pushed.
Some new(er) additions are:
* Support for opening chat (room) windows for channels that were
automatically joined. (Chat room initiated by the client library instead
of Jitsi.)
* Better support for IRC formatting control codes.
* Popup messages in case joining a channel fails (this is extremely
trivial, but it didn't work)
* And a few small tweaks for consistency, better handling of threading
and events, etc.

For now I need to do some slight tweaks, because of some confusion with
the way chat rooms are handled.
Also, I have contacted the author of the IRC client library and he
responded pretty enthusiastically about including the library in the IRC
implementation for Jitsi. I wanted to be sure he was still supporting
the library, since he was "off the radar" for a bit. He has already
included a few minor fixes, so currently I'm using an unmodified
development snapshot again.

I'm trying to finish up so we have something to merge, but I seem to end
up needing some slight changes here and there. I'm expecting one or two
other ones. After that we should be ready. (There's still a patch for
changes in Jitsi itself that isn't merged yet.)

Kind regards,
Danny

On 04/23/2014 12:32 PM, Marc Laporte wrote:
Hi Danny!

I hope you are well.

Is there anything new since what is here?
https://github.com/jitsi/jitsi/pull/16

I really really look forward to testing.

Thanks!

On Tue, Mar 25, 2014 at 5:26 PM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

On 03/25/2014 08:18 PM, Marc Laporte wrote:
Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen >>>> <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

#17

Hi Ingo,

Quick response there, thanks. I sent a patch, but this one wasn't too
long ago. The subject is "[jitsi-dev] [PATCH] Only create chat room if
the provider cannot find it". I'll make a pull request, but I need to
cherry-pick the commit out from between my other work.

The reason for the patch is fairly simple: Since chat room joins in IRC
can be initiated by the server, the protocol implementation already
created a chat room instance. If I then open a chat room window, Jitsi
immediately issues a 'create' operation, even though the chat room
already exists. According to the specs, a create operation should fail
with an exception if it already exists. So I've modified this to first
check for its existence.

As I said, I'll make a pull request on friday or in the weekend.

Kind regards,
Danny

···

On 04/23/2014 10:32 PM, Ingo Bauersachs wrote:

I guess the missing patch is not the isPrivate thing? Otherwise I don't see a pull request open or I just cannot find it. If it was a diff on the list, could you please open a pull request?

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

On 23.04.2014, at 21:57, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi Marc,

Thanks for your interest. I'm okay, just very busy with personal matters
at the moment.

The pull request is still current. It automatically includes more recent
changes that I've pushed.
Some new(er) additions are:
* Support for opening chat (room) windows for channels that were
automatically joined. (Chat room initiated by the client library instead
of Jitsi.)
* Better support for IRC formatting control codes.
* Popup messages in case joining a channel fails (this is extremely
trivial, but it didn't work)
* And a few small tweaks for consistency, better handling of threading
and events, etc.

For now I need to do some slight tweaks, because of some confusion with
the way chat rooms are handled.
Also, I have contacted the author of the IRC client library and he
responded pretty enthusiastically about including the library in the IRC
implementation for Jitsi. I wanted to be sure he was still supporting
the library, since he was "off the radar" for a bit. He has already
included a few minor fixes, so currently I'm using an unmodified
development snapshot again.

I'm trying to finish up so we have something to merge, but I seem to end
up needing some slight changes here and there. I'm expecting one or two
other ones. After that we should be ready. (There's still a patch for
changes in Jitsi itself that isn't merged yet.)

Kind regards,
Danny

On 04/23/2014 12:32 PM, Marc Laporte wrote:
Hi Danny!

I hope you are well.

Is there anything new since what is here?
https://github.com/jitsi/jitsi/pull/16

I really really look forward to testing.

Thanks!

On Tue, Mar 25, 2014 at 5:26 PM, Danny van Heumen >>> <danny@dannyvanheumen.nl> wrote:

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

On 03/25/2014 08:18 PM, Marc Laporte wrote:
Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen >>>>> <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

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

#18

Hi Danny!

I hope you are well.

Any news?

Thanks!

···

On Wed, Apr 23, 2014 at 5:15 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi Ingo,

Quick response there, thanks. I sent a patch, but this one wasn't too
long ago. The subject is "[jitsi-dev] [PATCH] Only create chat room if
the provider cannot find it". I'll make a pull request, but I need to
cherry-pick the commit out from between my other work.

The reason for the patch is fairly simple: Since chat room joins in IRC
can be initiated by the server, the protocol implementation already
created a chat room instance. If I then open a chat room window, Jitsi
immediately issues a 'create' operation, even though the chat room
already exists. According to the specs, a create operation should fail
with an exception if it already exists. So I've modified this to first
check for its existence.

As I said, I'll make a pull request on friday or in the weekend.

Kind regards,
Danny

On 04/23/2014 10:32 PM, Ingo Bauersachs wrote:

I guess the missing patch is not the isPrivate thing? Otherwise I don't see a pull request open or I just cannot find it. If it was a diff on the list, could you please open a pull request?

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

On 23.04.2014, at 21:57, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi Marc,

Thanks for your interest. I'm okay, just very busy with personal matters
at the moment.

The pull request is still current. It automatically includes more recent
changes that I've pushed.
Some new(er) additions are:
* Support for opening chat (room) windows for channels that were
automatically joined. (Chat room initiated by the client library instead
of Jitsi.)
* Better support for IRC formatting control codes.
* Popup messages in case joining a channel fails (this is extremely
trivial, but it didn't work)
* And a few small tweaks for consistency, better handling of threading
and events, etc.

For now I need to do some slight tweaks, because of some confusion with
the way chat rooms are handled.
Also, I have contacted the author of the IRC client library and he
responded pretty enthusiastically about including the library in the IRC
implementation for Jitsi. I wanted to be sure he was still supporting
the library, since he was "off the radar" for a bit. He has already
included a few minor fixes, so currently I'm using an unmodified
development snapshot again.

I'm trying to finish up so we have something to merge, but I seem to end
up needing some slight changes here and there. I'm expecting one or two
other ones. After that we should be ready. (There's still a patch for
changes in Jitsi itself that isn't merged yet.)

Kind regards,
Danny

On 04/23/2014 12:32 PM, Marc Laporte wrote:
Hi Danny!

I hope you are well.

Is there anything new since what is here?
https://github.com/jitsi/jitsi/pull/16

I really really look forward to testing.

Thanks!

On Tue, Mar 25, 2014 at 5:26 PM, Danny van Heumen >>>> <danny@dannyvanheumen.nl> wrote:

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

On 03/25/2014 08:18 PM, Marc Laporte wrote:
Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen >>>>>> <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

_______________________________________________
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

--
Marc Laporte

http://MarcLaporte.com
https://suite.tiki.org/Tiki+Suite
http://AvanTech.net

#19

Hi Marc,

I didn't notice your message until now. Everything is well. There were
some things including a job change that took up most of my time. Since
this week I am picking up development on the IRC protocol implementation
again.

There isn't much progress to report, I'm afraid. I have been trying to
finish up the initial implementation without making changes to core
Jitsi infrastructure, but I don't think that's realistic. I already
encountered a use case that requires changes to Jitsi's core because
Jitsi assumes a certain state that may not be valid anymore.
Furthermore, Ingo's remarks from a few months ago were valid. Since the
IRC protocol implementation itself is (also) initiating GUI operations
(in this case via MUCService) there are potential threading-issues. I
haven't given myself enough time yet to wrap my head around these cases,
so I might simply be taking the wrong approach.

All in all, the currently implementation is in a very decent condition.
You should be able to use it without too much trouble. But I'd need to
fix the current issues before merging it into Jitsi.

Anyways, still alive and kickin', though at a much slower pace than I
would've liked.

Kind regards,
Danny

···

On 06/27/2014 04:01 AM, Marc Laporte wrote:

Hi Danny!

I hope you are well.

Any news?

Thanks!

On Wed, Apr 23, 2014 at 5:15 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

Hi Ingo,

Quick response there, thanks. I sent a patch, but this one wasn't too
long ago. The subject is "[jitsi-dev] [PATCH] Only create chat room if
the provider cannot find it". I'll make a pull request, but I need to
cherry-pick the commit out from between my other work.

The reason for the patch is fairly simple: Since chat room joins in IRC
can be initiated by the server, the protocol implementation already
created a chat room instance. If I then open a chat room window, Jitsi
immediately issues a 'create' operation, even though the chat room
already exists. According to the specs, a create operation should fail
with an exception if it already exists. So I've modified this to first
check for its existence.

As I said, I'll make a pull request on friday or in the weekend.

Kind regards,
Danny

On 04/23/2014 10:32 PM, Ingo Bauersachs wrote:

I guess the missing patch is not the isPrivate thing? Otherwise I don't see a pull request open or I just cannot find it. If it was a diff on the list, could you please open a pull request?

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

On 23.04.2014, at 21:57, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi Marc,

Thanks for your interest. I'm okay, just very busy with personal matters
at the moment.

The pull request is still current. It automatically includes more recent
changes that I've pushed.
Some new(er) additions are:
* Support for opening chat (room) windows for channels that were
automatically joined. (Chat room initiated by the client library instead
of Jitsi.)
* Better support for IRC formatting control codes.
* Popup messages in case joining a channel fails (this is extremely
trivial, but it didn't work)
* And a few small tweaks for consistency, better handling of threading
and events, etc.

For now I need to do some slight tweaks, because of some confusion with
the way chat rooms are handled.
Also, I have contacted the author of the IRC client library and he
responded pretty enthusiastically about including the library in the IRC
implementation for Jitsi. I wanted to be sure he was still supporting
the library, since he was "off the radar" for a bit. He has already
included a few minor fixes, so currently I'm using an unmodified
development snapshot again.

I'm trying to finish up so we have something to merge, but I seem to end
up needing some slight changes here and there. I'm expecting one or two
other ones. After that we should be ready. (There's still a patch for
changes in Jitsi itself that isn't merged yet.)

Kind regards,
Danny

On 04/23/2014 12:32 PM, Marc Laporte wrote:
Hi Danny!

I hope you are well.

Is there anything new since what is here?
https://github.com/jitsi/jitsi/pull/16

I really really look forward to testing.

Thanks!

On Tue, Mar 25, 2014 at 5:26 PM, Danny van Heumen >>>>> <danny@dannyvanheumen.nl> wrote:

Hi,

Thanks for the comments. Sure, no prob, although I haven't had too much
time lately.
Something a little bit more unfortunate is that the author of the IRC
client library hasn't responded in a while. So I will probably need to
set up a local repo at least temporarily with the few minor
modifications that I did. It's not that big of a problem though.

Anyways, to be continued ...

Danny

On 03/25/2014 08:18 PM, Marc Laporte wrote:
Hi Danny!

Thank you very much for all your energy on this.

I really really look forward to testing.

Thanks!!

On Wed, Mar 19, 2014 at 4:52 PM, Danny van Heumen >>>>>>> <danny@dannyvanheumen.nl> wrote:

Hi Ingo and others,

I did not yet respond w.r.t. the pull request. I discovered some
unexpected behavior last week for a case of a channel join initiated by
the IRC server. I am currently working that out and will come back to
you after that.

Kind regards,
Danny

On 03/04/2014 08:58 PM, Ingo Bauersachs wrote:

Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.

Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.

I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.

Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.

Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be

desirable.

As much as I personally dislike it: they need to be split up.

It's probably weekend before I have a decent amount of time to do these
kinds of things.

I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.

I think it simply got under the carpet, sorry!

Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:

I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?

- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code

Okay.

There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
thing.

Good!

I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.

That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
recognized practice.

So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
way?

If the pull request is up to date, I'm going for it.

Kind regards,
Danny

Ingo

_______________________________________________
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

_______________________________________________
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