Re: [ecf-dev] ECF ChatClient

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 10/19/2013 12:03 AM, Wim Jongman wrote:
>> Can you shortly outline what the server is (supposed to be) doing and
>> what the above means?
>>
> 
> Sure. The server advertises a ChatServer service which is consumed by the
> clients. The clients can post messages into this server. This works fine.
> 
> The idea (yours actually) is that the clients advertise a Listener
> (ICatListener) that gets consumed by the server and called upon receiving a
> new message. This does not work if the Server runs on the same machine as
> the discovery server. Hence my message stating that we have to run this on
> a separate server.

Running the discovery server and distribution on the same host should
actually work. It might be though, that it filters discovery events
coming from localhost.

>> PS: org.eclipse.ecf.example.chat.model.IChatServer.getMessages(Long)
>> requires a timestamp. This is kind of fuzzy as the clocks of the nodes
>> are not synchronized and never can be in a distributed system? Why not
>> use a simpler message counter at the server that enumerates the chat
>> messages? Semantically it would change the getMessage's javadoc comment
>> from "Get the messages since the passed time." to "Get the messages
>> since message N."
>>
> 
> I do exactly that only not with a counter but with the server's time. The
> reason I did not use a counter is that this frees the server from the
> implied duty to keep all messages. E.g. if the client gets counter 27 it
> might expect to get 27 messages. Using this magic time does not imply any
> result length.

I do not find a method where clients can get the server timestamp.

>> org.eclipse.ecf.example.chat.server.core.internal.ChatServer.doBackGroundNotify(ArrayList<IChatServerListener>,
>> Long) as part of the for loop.
>>
> 
> I move the listeners to a new list to prevent a possible lock when a new
> listener comes in _during_ listener notification. Note that I have not
> gotten this to work.

I also pushed a version to github that uses a map to store
handles->listeners

M.