Re: [Dpp-devel] [Patch] bugfix - partner saving not transmitted

[Andreas L. (FU Informatik) <lin...@in...>]

Hi Christopher,

> ...
> Second bug:
> 
> A=host+driver,B=client+observer+followMode(A)
> 
> 1.) A opens a.txt
> 
> 2.) edits a.txt
> 
> PostCondition: a.txt is modified for A and B
> 
> 3.) A makes A=observer
> 
> PostCondition: A=host+observer, B=client+observer+followMode(A)
> 
> 4.) A saves
> 
> PostCondition: a.txt is modified for A and not for B
> 
> 5.) A makes A=driver
> 
> PostCondition: A=host+driver, B=client+observer+followMode(A)
> 
> 6.) A renames a.txt
> 
> 7.) Bug2: Inconsistencies?
> 
> Is this correct?
> 
[Lindner, Andreas] 
You are right as this is a bug too, but the effects are more interesting than You describe them. In addition to the inconsistencies an assertion error occurs (probably only in debug mode).
Firstly: Is there a bug in the bug tracker for that 'second bug'?
Secondly: I was not talking about this, I talked about renaming directly after your first described scenario. My intension was to show you the upcoming inconsistencies (one could say: 'I don't care about the asterisk or the file system').
I don't understand why this takes place? When the stateListener is unregistered for a role switch my initial patch seems to be correct? It will be correctly unregistered (You may correct me here if I am wrong, please) when it is about time. [1]

> It makes sense that Saros would not save the file if it does not
> believe
> it is dirty. File Operations would then likely lead to inconsistencies.
> We
> should improve the dirtyChecks to directly ask the document and not the
> dirtyListener
[Lindner, Andreas] 
I don't understand. If this makes sense we can ignore if files are dirty or not. We rely on what Saros define "dirty".
I thought it makes sense that a file is saved on both sides? It sounds contradictory to me ('it makes sense' - 'would then likely lead to inconsistencies') so I think I do not understand what You mean.
What is wrong with listening, it sounds like You prefer polling instead?

> Troubling. You should try to investigate these failures.
[Lindner, Andreas] 
Sorry but this is not practical. When we work on another project it is not the time to investigate bugs in the tools we use. Especially when the bugs slow our work down in the first place.

> Well lets think about a solution, which works. Obviously if we register
> a
> listener then we need to remove the listener at some point. At the
> moment
> we register the same listener for each File which is opened and remove
> it
> for each File which is closed.
> 
> The bug arises, because the same listener cannot be added twice
> (Eclipse
> ignores it).
> 
> 2 Solutions come to mind:
>    1. Reference counting - Keep track of how many files are opened,
> remove
> when the last file is closed.
>    2. Use a new listener for each file - Adding and removing is simple,
> each listener will only get events from a single file.
> 
> Think about which solution you prefer and fix this bug for real.
[Lindner, Andreas] 
I don't really like the idea of reference counting at this point. It seems to be error prone.
The second one looks better to me. To do this I need a bit mor information about Eclipse. You used an interface called IElementStateListener which is registered on an IDocumentProvider which seems to be general for all the files? How can I register an IElementStateListener (or similar) to an independent file?

[1] Maybe the solution for this 'second Bug' solves the other bug as well? After Your last email I thought the EditorPool#remove method is the only one that unregisters those listeners. Now I think that another one is doing so, too (e.g. the one responsible for role management). Do You have any ideas about this?



Regards
Andreas