[jitsi-dev] Editing Jitsi configuration file


#1

Sorry, I forgot to commit to local repo before patching.
Here is the latest patch:

propseditor.patch (97.2 KB)


#2

Hello,

···

On 8/9/13 12:22 PM, Marin Dzhigarov wrote:

Sorry, I forgot to commit to local repo before patching.
Here is the latest patch:

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

Very useful, indeed!

Minor comment: You've stripped the LGPL header and the class javadoc
from SearchFieldUI.java

Feature request: could we have ordering by property by default?

Regards,
Boris


#3

Pushed into jitsi/jitsi's master as commit
b4c90af94926b9904ba2e75286339faad986c0bb.


#4

Thanks a lot!

I've just acked him on Team and Contributors.

Could you please let him know tomorrow that we've committed this?

Emil

···

On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov <lyubomir.marinov@jitsi.org> wrote:

Pushed into jitsi/jitsi's master as commit
b4c90af94926b9904ba2e75286339faad986c0bb.

_______________________________________________
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


#5

Thanks!

···

On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:

Thanks a lot!

I've just acked him on Team and Contributors.

Could you please let him know tomorrow that we've committed this?

Emil

On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov > <lyubomir.marinov@jitsi.org> wrote:
> Pushed into jitsi/jitsi's master as commit
> b4c90af94926b9904ba2e75286339faad986c0bb.
>
> _______________________________________________
> 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

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


#6

Hello,

Just a minor change - added ordering by property by default to the
properties editor plugin.

Marin

ordering by property by default.patch (2.8 KB)

···

On Wed, Aug 28, 2013 at 9:58 AM, Marin Dzhigarov <marin@bluejimp.com> wrote:

Thanks!

On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:

Thanks a lot!

I've just acked him on Team and Contributors.

Could you please let him know tomorrow that we've committed this?

Emil

On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov >> <lyubomir.marinov@jitsi.org> wrote:
> Pushed into jitsi/jitsi's master as commit
> b4c90af94926b9904ba2e75286339faad986c0bb.
>
> _______________________________________________
> 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

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


#7

Hello,

Emil asked me to optimize the search so that it behaves better on a larger
configuration file.

So I did some changes on
the net.java.sip.communicator.plugin.propertieseditor.PropsTableModel so
that instead of constantly accessing the data from the configuration
service, it caches the properties in a LinkedHashMap.

Please take a minute to review the changes.

Thanks in advance!

Marin

optimized search on props editor.patch (10.9 KB)

···

On Thu, Aug 29, 2013 at 12:09 PM, Marin Dzhigarov <marin@bluejimp.com>wrote:

Hello,

Just a minor change - added ordering by property by default to the
properties editor plugin.

Marin

On Wed, Aug 28, 2013 at 9:58 AM, Marin Dzhigarov <marin@bluejimp.com>wrote:

Thanks!

On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:

Thanks a lot!

I've just acked him on Team and Contributors.

Could you please let him know tomorrow that we've committed this?

Emil

On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov >>> <lyubomir.marinov@jitsi.org> wrote:
> Pushed into jitsi/jitsi's master as commit
> b4c90af94926b9904ba2e75286339faad986c0bb.
>
> _______________________________________________
> 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

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


#8

Hey Marin,

I haven't looked into the patch yet but judging from your description
this doesn't sound like the right way to handle things.

First of all, the current implementation of the configuration service
already stored all properties in memory so I don't think this change
is likely to change things substantially.

More importantly however, it is not appropriate for this editor to
clone all the data from the configuration service. We are thinking of
using an embedded DB in the configuration service in order to avoid
having to ever load all the data. If at that point the editor still
clones everything this would be pointless.

Note that we don't really care how fast the searches in the editor
complete. This is not a critical aspect of the application so a search
would be satisfactory regardless of whether it takes 10ms, 100ms or
1000ms.

What does matter however is that while the search is being performed
the application continues to behave properly. The current version
would simply block until the search is over. During that time it would
be impossible to type other letters or (in some cases) do anything
with the Jitsi GUI.

I therefore asked you to make sure that as much of the search as
possible happens in a different thread. The actual GUI update would
obviously still need to happen in the AWT/Swing thread but it would
be with a "low priority".

Does this make sense?

Emil

···

On Tue, Sep 3, 2013 at 10:32 AM, Marin Dzhigarov <marin@bluejimp.com> wrote:

Hello,

Emil asked me to optimize the search so that it behaves better on a larger
configuration file.

So I did some changes on the
net.java.sip.communicator.plugin.propertieseditor.PropsTableModel so that
instead of constantly accessing the data from the configuration service, it
caches the properties in a LinkedHashMap.

Please take a minute to review the changes.

Thanks in advance!

Marin

On Thu, Aug 29, 2013 at 12:09 PM, Marin Dzhigarov <marin@bluejimp.com> > wrote:

Hello,

Just a minor change - added ordering by property by default to the
properties editor plugin.

Marin

On Wed, Aug 28, 2013 at 9:58 AM, Marin Dzhigarov <marin@bluejimp.com> >> wrote:

Thanks!

On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:

Thanks a lot!

I've just acked him on Team and Contributors.

Could you please let him know tomorrow that we've committed this?

Emil

On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov >>>> <lyubomir.marinov@jitsi.org> wrote:
> Pushed into jitsi/jitsi's master as commit
> b4c90af94926b9904ba2e75286339faad986c0bb.
>
> _______________________________________________
> 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

_______________________________________________
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


#9

Hey Marin, Emil,

Hey Marin,

I haven't looked into the patch yet but judging from your description
this doesn't sound like the right way to handle things.

First of all, the current implementation of the configuration service
already stored all properties in memory so I don't think this change
is likely to change things substantially.

More importantly however, it is not appropriate for this editor to
clone all the data from the configuration service. We are thinking of
using an embedded DB in the configuration service in order to avoid
having to ever load all the data. If at that point the editor still
clones everything this would be pointless.

Agree.

Note that we don't really care how fast the searches in the editor
complete. This is not a critical aspect of the application so a search
would be satisfactory regardless of whether it takes 10ms, 100ms or
1000ms.

What does matter however is that while the search is being performed
the application continues to behave properly. The current version
would simply block until the search is over. During that time it would
be impossible to type other letters or (in some cases) do anything
with the Jitsi GUI.

I therefore asked you to make sure that as much of the search as
possible happens in a different thread. The actual GUI update would
obviously still need to happen in the AWT/Swing thread but it would
be with a "low priority".

We've actually discussed this with Marin off-list. He had chosen to use the table sorter directly, which makes the sort and the refresh of the view internally, so we don't have many options with this one. When discussing with Marin we decided to try to call the sort of the table in a separate thread or call it in a low priority thread and see how it goes. I see in the patch that you've chosen the latter. Did this make any difference? If on the other hand this operation has slow down the actual sort (search) then we should simply use another approach, may be similar to that in the contact list (implementing the search ourselves and making sure the search happens in a separate thread and the gui is updated with low priority in the event dispatch thread).

Cheers,
Yana

···

On Sep 3, 2013, at 1:15 PM, Emil Ivov <emcho@jitsi.org> wrote:

Does this make sense?

Emil

On Tue, Sep 3, 2013 at 10:32 AM, Marin Dzhigarov <marin@bluejimp.com> wrote:

Hello,

Emil asked me to optimize the search so that it behaves better on a larger
configuration file.

So I did some changes on the
net.java.sip.communicator.plugin.propertieseditor.PropsTableModel so that
instead of constantly accessing the data from the configuration service, it
caches the properties in a LinkedHashMap.

Please take a minute to review the changes.

Thanks in advance!

Marin

On Thu, Aug 29, 2013 at 12:09 PM, Marin Dzhigarov <marin@bluejimp.com> >> wrote:

Hello,

Just a minor change - added ordering by property by default to the
properties editor plugin.

Marin

On Wed, Aug 28, 2013 at 9:58 AM, Marin Dzhigarov <marin@bluejimp.com> >>> wrote:

Thanks!

On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:

Thanks a lot!

I've just acked him on Team and Contributors.

Could you please let him know tomorrow that we've committed this?

Emil

On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov >>>>> <lyubomir.marinov@jitsi.org> wrote:

Pushed into jitsi/jitsi's master as commit
b4c90af94926b9904ba2e75286339faad986c0bb.

_______________________________________________
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

_______________________________________________
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

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


#10

Hey Marin,

I haven't looked into the patch yet but judging from your description
this doesn't sound like the right way to handle things.

First of all, the current implementation of the configuration service
already stored all properties in memory so I don't think this change
is likely to change things substantially.

More importantly however, it is not appropriate for this editor to
clone all the data from the configuration service. We are thinking of
using an embedded DB in the configuration service in order to avoid
having to ever load all the data. If at that point the editor still
clones everything this would be pointless.

Understood.

When discussing with Marin we decided to try to call the sort of the

table in a separate thread or call it in a low priority thread and > see
how it goes. I see in the patch that you've chosen the latter. Did this
make any difference?

No, it didn't.

may be similar to that in the contact list (implementing the search

ourselves and making sure the search happens in a separate

thread and the gui is updated with low priority in the event dispatch

thread).

Okay, I will take care of this.

Marin

···

On Tue, Sep 3, 2013 at 2:31 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hey Marin, Emil,

On Sep 3, 2013, at 1:15 PM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey Marin,
>
> I haven't looked into the patch yet but judging from your description
> this doesn't sound like the right way to handle things.
>
> First of all, the current implementation of the configuration service
> already stored all properties in memory so I don't think this change
> is likely to change things substantially.
>
> More importantly however, it is not appropriate for this editor to
> clone all the data from the configuration service. We are thinking of
> using an embedded DB in the configuration service in order to avoid
> having to ever load all the data. If at that point the editor still
> clones everything this would be pointless.

Agree.

>
> Note that we don't really care how fast the searches in the editor
> complete. This is not a critical aspect of the application so a search
> would be satisfactory regardless of whether it takes 10ms, 100ms or
> 1000ms.
>
> What does matter however is that while the search is being performed
> the application continues to behave properly. The current version
> would simply block until the search is over. During that time it would
> be impossible to type other letters or (in some cases) do anything
> with the Jitsi GUI.
>
> I therefore asked you to make sure that as much of the search as
> possible happens in a different thread. The actual GUI update would
> obviously still need to happen in the AWT/Swing thread but it would
> be with a "low priority".

We've actually discussed this with Marin off-list. He had chosen to use
the table sorter directly, which makes the sort and the refresh of the view
internally, so we don't have many options with this one. When discussing
with Marin we decided to try to call the sort of the table in a separate
thread or call it in a low priority thread and see how it goes. I see in
the patch that you've chosen the latter. Did this make any difference? If
on the other hand this operation has slow down the actual sort (search)
then we should simply use another approach, may be similar to that in the
contact list (implementing the search ourselves and making sure the search
happens in a separate thread and the gui is updated with low priority in
the event dispatch thread).

Cheers,
Yana

>
> Does this make sense?
>
> Emil
>
> On Tue, Sep 3, 2013 at 10:32 AM, Marin Dzhigarov <marin@bluejimp.com> > wrote:
>> Hello,
>>
>> Emil asked me to optimize the search so that it behaves better on a
larger
>> configuration file.
>>
>> So I did some changes on the
>> net.java.sip.communicator.plugin.propertieseditor.PropsTableModel so
that
>> instead of constantly accessing the data from the configuration
service, it
>> caches the properties in a LinkedHashMap.
>>
>> Please take a minute to review the changes.
>>
>> Thanks in advance!
>>
>> Marin
>>
>>
>> On Thu, Aug 29, 2013 at 12:09 PM, Marin Dzhigarov <marin@bluejimp.com> > >> wrote:
>>>
>>> Hello,
>>>
>>> Just a minor change - added ordering by property by default to the
>>> properties editor plugin.
>>>
>>> Marin
>>>
>>>
>>> On Wed, Aug 28, 2013 at 9:58 AM, Marin Dzhigarov <marin@bluejimp.com> > >>> wrote:
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>> I've just acked him on Team and Contributors.
>>>>>
>>>>> Could you please let him know tomorrow that we've committed this?
>>>>>
>>>>> Emil
>>>>>
>>>>> On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov > >>>>> <lyubomir.marinov@jitsi.org> wrote:
>>>>>> Pushed into jitsi/jitsi's master as commit
>>>>>> b4c90af94926b9904ba2e75286339faad986c0bb.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> 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


#11

Hello all,

The patch is ready. As much of the search as possible is done in a separate
thread.

Any comments will be appreciated.

Regards,
Marin

Optimized search on properties editor.patch (16.4 KB)

···

On Tue, Sep 3, 2013 at 3:12 PM, Marin Dzhigarov <marin@bluejimp.com> wrote:

> Hey Marin,
>
> I haven't looked into the patch yet but judging from your description
> this doesn't sound like the right way to handle things.
>
> First of all, the current implementation of the configuration service
> already stored all properties in memory so I don't think this change
> is likely to change things substantially.
>
> More importantly however, it is not appropriate for this editor to
> clone all the data from the configuration service. We are thinking of
> using an embedded DB in the configuration service in order to avoid
> having to ever load all the data. If at that point the editor still
> clones everything this would be pointless.

Understood.

> When discussing with Marin we decided to try to call the sort of the
table in a separate thread or call it in a low priority thread and > see
how it goes. I see in the patch that you've chosen the latter. Did this
make any difference?

No, it didn't.

> may be similar to that in the contact list (implementing the search
ourselves and making sure the search happens in a separate
> thread and the gui is updated with low priority in the event dispatch
thread).

Okay, I will take care of this.

Marin

On Tue, Sep 3, 2013 at 2:31 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hey Marin, Emil,

On Sep 3, 2013, at 1:15 PM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey Marin,
>
> I haven't looked into the patch yet but judging from your description
> this doesn't sound like the right way to handle things.
>
> First of all, the current implementation of the configuration service
> already stored all properties in memory so I don't think this change
> is likely to change things substantially.
>
> More importantly however, it is not appropriate for this editor to
> clone all the data from the configuration service. We are thinking of
> using an embedded DB in the configuration service in order to avoid
> having to ever load all the data. If at that point the editor still
> clones everything this would be pointless.

Agree.

>
> Note that we don't really care how fast the searches in the editor
> complete. This is not a critical aspect of the application so a search
> would be satisfactory regardless of whether it takes 10ms, 100ms or
> 1000ms.
>
> What does matter however is that while the search is being performed
> the application continues to behave properly. The current version
> would simply block until the search is over. During that time it would
> be impossible to type other letters or (in some cases) do anything
> with the Jitsi GUI.
>
> I therefore asked you to make sure that as much of the search as
> possible happens in a different thread. The actual GUI update would
> obviously still need to happen in the AWT/Swing thread but it would
> be with a "low priority".

We've actually discussed this with Marin off-list. He had chosen to use
the table sorter directly, which makes the sort and the refresh of the view
internally, so we don't have many options with this one. When discussing
with Marin we decided to try to call the sort of the table in a separate
thread or call it in a low priority thread and see how it goes. I see in
the patch that you've chosen the latter. Did this make any difference? If
on the other hand this operation has slow down the actual sort (search)
then we should simply use another approach, may be similar to that in the
contact list (implementing the search ourselves and making sure the search
happens in a separate thread and the gui is updated with low priority in
the event dispatch thread).

Cheers,
Yana

>
> Does this make sense?
>
> Emil
>
> On Tue, Sep 3, 2013 at 10:32 AM, Marin Dzhigarov <marin@bluejimp.com> >> wrote:
>> Hello,
>>
>> Emil asked me to optimize the search so that it behaves better on a
larger
>> configuration file.
>>
>> So I did some changes on the
>> net.java.sip.communicator.plugin.propertieseditor.PropsTableModel so
that
>> instead of constantly accessing the data from the configuration
service, it
>> caches the properties in a LinkedHashMap.
>>
>> Please take a minute to review the changes.
>>
>> Thanks in advance!
>>
>> Marin
>>
>>
>> On Thu, Aug 29, 2013 at 12:09 PM, Marin Dzhigarov <marin@bluejimp.com> >> >> wrote:
>>>
>>> Hello,
>>>
>>> Just a minor change - added ordering by property by default to the
>>> properties editor plugin.
>>>
>>> Marin
>>>
>>>
>>> On Wed, Aug 28, 2013 at 9:58 AM, Marin Dzhigarov <marin@bluejimp.com> >> >>> wrote:
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> On Wed, Aug 28, 2013 at 1:21 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>> I've just acked him on Team and Contributors.
>>>>>
>>>>> Could you please let him know tomorrow that we've committed this?
>>>>>
>>>>> Emil
>>>>>
>>>>> On Wed, Aug 28, 2013 at 12:02 AM, Lyubomir Marinov >> >>>>> <lyubomir.marinov@jitsi.org> wrote:
>>>>>> Pushed into jitsi/jitsi's master as commit
>>>>>> b4c90af94926b9904ba2e75286339faad986c0bb.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> 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


#12

Pushed into jitsi/jitsi's master
as commit 2f3339dacf8bd16af1ea642a125d632319d0a454 and acknowledged on
our Team and Contributors page at https://jitsi.org.

Thank you, Marin!

I made substantial changes to the implementation of the background
thread which performs the actual filtering because you made it live
forever which I found undesirable. It will now die after idling for 5
minutes. Generally, the lifespans of threads are important because,
for example, a Thread is a garbage collection root i.e. a Thread will
keep whatever it references from being garbage collected.

I also removed fields here and there because they were in fact
unnecessary, made most of them final.

I'm not entirely sure why you moved the filtering into a background
thread and yet left the sorting to the JTable. JTable does the
filtering as part of the sorting. Do you have any thoughts and/or
observations on the subject?

I'm also a bit interested into the table model. It's practically a
two-dimensional array which requires the allocation of an array per
property whenever you're rebuilding the model. Which isn't great with
respect to the heap and the garbage collector. Have you considered a
table model based on the property names alone and then looking up
their values in the ConfigurationService whenever the JTable asks
about them? I guess that would be computationally more intensive than
your approach.


#13

First of all thank you for the great review!

I'm also a bit interested into the table model. It's practically a
two-dimensional array which requires the allocation of an array per
property whenever you're rebuilding the model. Which isn't great with
respect to the heap and the garbage collector. Have you considered a
table model based on the property names alone and then looking up
their values in the ConfigurationService whenever the JTable asks
about them? I guess that would be computationally more intensive than
your approach.

I see your concern but Emil explicitly wanted the TableModel of the
properties table to contain only those properties that were shown in the
table and not cache all properties in the ConfigurationService. So Yana and
I discussed that it can either be added support for filtering to the
ConfigurationService or a separate thread can be made to filter properties
in a result set and push them to the table. We chose the second option so I
can not see how we can avoid making an array per property.

I made substantial changes to the implementation of the background
thread which performs the actual filtering because you made it live
forever which I found undesirable. It will now die after idling for 5
minutes. Generally, the lifespans of threads are important because,
for example, a Thread is a garbage collection root i.e. a Thread will
keep whatever it references from being garbage collected.

Good point. I also support the idea that we should keep the thread count to
a minimum as far as worker threads are concerned.

Actually, the filtering in the contact list is done in a similar way - the
thread lives forever so this is why I decided to do it like that.
But now that Lyubomir mentioned it, Yana, is there any specific reason why
the net.java.sip.communicator.impl.gui.main.contactlist.TreeContactList.FilterThread
is not a daemon thread and lives forever? May be we should change that too..

I'm not entirely sure why you moved the filtering into a background
thread and yet left the sorting to the JTable. JTable does the
filtering as part of the sorting. Do you have any thoughts and/or
observations on the subject?

Ideally, the sorting also should be in a separate thread. However, given
that RowSorter is already implemented in the JDK and the sorting by
property names seems to me like just a luxury I think that it is not worth
the time to invest in implementing a sorter class in the case of the
properties editor plugin. I might be wrong though, what do you all think
about that?

Regards,
Marin

···

On Wed, Sep 11, 2013 at 2:48 AM, Lyubomir Marinov < lyubomir.marinov@jitsi.org> wrote:

Pushed into jitsi/jitsi's master
as commit 2f3339dacf8bd16af1ea642a125d632319d0a454 and acknowledged on
our Team and Contributors page at https://jitsi.org.

Thank you, Marin!

I made substantial changes to the implementation of the background
thread which performs the actual filtering because you made it live
forever which I found undesirable. It will now die after idling for 5
minutes. Generally, the lifespans of threads are important because,
for example, a Thread is a garbage collection root i.e. a Thread will
keep whatever it references from being garbage collected.

I also removed fields here and there because they were in fact
unnecessary, made most of them final.

I'm not entirely sure why you moved the filtering into a background
thread and yet left the sorting to the JTable. JTable does the
filtering as part of the sorting. Do you have any thoughts and/or
observations on the subject?

I'm also a bit interested into the table model. It's practically a
two-dimensional array which requires the allocation of an array per
property whenever you're rebuilding the model. Which isn't great with
respect to the heap and the garbage collector. Have you considered a
table model based on the property names alone and then looking up
their values in the ConfigurationService whenever the JTable asks
about them? I guess that would be computationally more intensive than
your approach.

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