HistoryReaderImpl

Hello Damian,

I was hoovering over the HistoryReaderImpl class and have a
couple of 
minor remarks to make.

1) You seem to use the same event instance for every
progress event. 
This could lead to race conditions for listeners that handle
their 
progress events in a separate thread. I guess you could
simply take all 
params necessary for the progress event constructor in the
fire method 
and create the event inside it.

2) Some lines go over column 80

Concerning one, Yana mentioned that she had a problem with
event 
dispatching of this event. I wonder whether this could have
anything to 
do with it.

Yana are you handling such events in a separate thread?

Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Emil Ivov wrote:
> Hello Damian,
>
> I was hoovering over the HistoryReaderImpl class and
have a couple of 
> minor remarks to make.
>
> 1) You seem to use the same event instance for every
progress event. 
> This could lead to race conditions for listeners that
handle their 
> progress events in a separate thread. I guess you could
simply take 
> all params necessary for the progress event constructor
in the fire 
> method and create the event inside it.
Will be fixed.
>
> 2) Some lines go over column 80
>
Not so much, but will be fixed.

But I had other problem with the history.
For the incoming messages and the records in the history
there are two 
dates.
The first is the one coming from the protocol (in many cases
is some how 
wrong)
The second is the one  when the message is received on the
client machine.

When retrieving records and passing them out of the 
MessageHistoryService here is the behavior of the service :
If the message has date (this is put for compability because
in the 
first release of HistoryService there was only one timestamp
)
this date is the timestamp of the 
MessageDeliveredEvent/MessageReceivedEvent if date is null
the date of 
the receiving the message is put.
But some times this date is wrong For exmaple may be in the
future. What 
happens when its in the future.
When reading records by date - the filename  is used as
timestamp and 
must be  between the searched dates. So there is no such
file
with future date so no messages are returned (but they
exist). The same 
happens and if the date is just wrong.
As I wrote this I realize that when search for messages by
date in given 
xml I compare the given dates with the timestamp of the
received 
message  on the client machine not the date that came from
the protocol.

Everything became so messy . Any ideas ?

damencho

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

> But I had other problem with the history.
> For the incoming messages and the records in the
history there are two 
> dates.
> The first is the one coming from the protocol (in many
cases is some how 
> wrong)

I've recently added a fix in
OperationSetBasicInstantMessagingIcqImpl 
making sure that messages with a timestamp more than 24h
away from the 
current time, will be fixed to contain the current date as a
timestamp. 
Maybe this will reduce the number of wrongful messages.

I guess that you could do something similar. If I am not
wrong, in the 
history files you store messages sequentially. So if, during
a search, 
you encounter a message with a date that goes beyond the
date of the 
next message you know something is wrong. In such a case you
could 
replace it with a dummy date located (for example) 1
millisecond before 
the date of the message after it, or 1 millisecond after the
message 
preceding it. You could even do the change in the file
itself and store 
it, so that you don't come across the same problem every
time you do a 
search.

How does this sound?

Emil

> When retrieving records and passing them out of the 
> MessageHistoryService here is the behavior of the
service :
> If the message has date (this is put for compability
because in the 
> first release of HistoryService there was only one
timestamp )
> this date is the timestamp of the 
> MessageDeliveredEvent/MessageReceivedEvent if date is
null the date of 
> the receiving the message is put.
> But some times this date is wrong For exmaple may be in
the future. What 
> happens when its in the future.
> When reading records by date - the filename  is used as
timestamp and 
> must be  between the searched dates. So there is no
such file
> with future date so no messages are returned (but they
exist). The same 
> happens and if the date is just wrong.
> As I wrote this I realize that when search for messages
by date in given 
> xml I compare the given dates with the timestamp of the
received 
> message  on the client machine not the date that came
from the protocol.
> 
> Everything became so messy . Any ideas ?
> 
> damencho
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Emil Ivov wrote:
>
> I've recently added a fix in
OperationSetBasicInstantMessagingIcqImpl 
> making sure that messages with a timestamp more than
24h away from the 
> current time, will be fixed to contain the current date
as a 
> timestamp. Maybe this will reduce the number of
wrongful messages.
>
> I guess that you could do something similar. If I am
not wrong, in the 
> history files you store messages sequentially. So if,
during a search, 
> you encounter a message with a date that goes beyond
the date of the 
> next message you know something is wrong. In such a
case you could 
> replace it with a dummy date located (for example) 1
millisecond 
> before the date of the message after it, or 1
millisecond after the 
> message preceding it. You could even do the change in
the file itself 
> and store it, so that you don't come across the same
problem every 
> time you do a search.
>
> How does this sound?
>
> Emil
I cannot see how does will fix the things with current wrong
records and 
future dates.
I think that it is good all searches and shown dates in the
history 
window(on the left of the window) to be done with the dates
of the 
messages received on the client machine
and the use of the dates that came from protocol to be only
when showing 
the actual messages (on the right of history window)

Is it ok ?

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Damian Minkov wrote:
> Emil Ivov wrote:
>> I've recently added a fix in
OperationSetBasicInstantMessagingIcqImpl 
>> making sure that messages with a timestamp more
than 24h away from the 
>> current time, will be fixed to contain the current
date as a 
>> timestamp. Maybe this will reduce the number of
wrongful messages.
>>
>> I guess that you could do something similar. If I
am not wrong, in the 
>> history files you store messages sequentially. So
if, during a search, 
>> you encounter a message with a date that goes
beyond the date of the 
>> next message you know something is wrong. In such a
case you could 
>> replace it with a dummy date located (for example)
1 millisecond 
>> before the date of the message after it, or 1
millisecond after the 
>> message preceding it. You could even do the change
in the file itself 
>> and store it, so that you don't come across the
same problem every 
>> time you do a search.
>>
>> How does this sound?
>>
>> Emil
> I cannot see how does will fix the things with current
wrong records and 
> future dates.

Let's say that today the date is 10. We are running the
sip-communicator 
and it hase opened a file named "10" where it
stores messages that we're 
currently receiving and sending. Let's now imagine that a
message 
arrives with date 1500. Earlier versions of the
sip-communicator would 
have stored this message in file 10 but would have kept its
date 1500. 
Let's now imagine that the next message that arrives has a
correct date 
- 10 again. So in your file 10.xml you would have messages
with dates 
10, 1500 and 10, recorded in the order they were received.
Am I right?

If this is the case then when you stumble upon such a record
- with a 
date past the  date of the message recorded after it, you
could simply 
change its date to a date between the dates of the messages 
before and 
after it. Is this clearer now?

> I think that it is good all searches and shown dates in
the history 
> window(on the left of the window) to be done with the
dates of the 
> messages received on the client machine
> and the use of the dates that came from protocol to be
only when showing 
> the actual messages (on the right of history window)
> 
> Is it ok ?

Yes it's ok for you to do so from now on. What I suggest
above is 
something that should take care of existing bad records.

Emil
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi iana,
Something I just saw. Recently we add case in/sensitive
search. The 
default behavior is case insensitive but I saw that the word
that
was searched if is not the same case as the found one . The
found word 
is not highlighted !

damencho

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Damian,

You're right. I have fixed that. You could try it now.

yana

Damian Minkov wrote:
> Hi iana,
> Something I just saw. Recently we add case in/sensitive
search. The 
> default behavior is case insensitive but I saw that the
word that
> was searched if is not the same case as the found one .
The found word 
> is not highlighted !
>
> damencho
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net