Community
Participate
Working Groups
Text documents should support a life-cycle API (as an extension interface) so that IDocument implementations need not rely on the garbage collector for freeing resources. Documents may hold a large amount of memory/resources which should be allocated and disposed in a controlled manner. This would IMO also be more consistent with ResourceTextFileBuffer which defines a dispose method, but the main resource which the text buffer holds (a document) cannot be explicetly disposed. As a concrete example, we have an IDocument implementation which uses temporary files as underlying text buffer. The temporary files must be deleted when the document is no longer needed. Without a clear life-cycle API, deleting of the files has to be left to the garbage collector or some delete-on-exit mechanism. Clearly this enhancement potentially affects all IDocument clients as they would have to add checks if a particular document implements the life-cycle API and whether it is disposed or not, therefore I don't really expect this enhancement to come true soon ;-)
>s a concrete example, we have an IDocument implementation which uses temporary >files as underlying text buffer. Couldn't you write your own file buffer that handles this and use it instead of the document where appropriate?
Hm, I probably don't quite get your point, but it need be an IDocument. The document is created by an IDocumentFactory which is registered for certain file types. Document instances created this way are simply out of control. It is possible to have a listener observe the disposal of the ITextFileBuffer and dispose the document/delete the temporary files in that same moment, but it appears that this is too aggressive, because the document might still be used.
Note that IDocumentFactory has been deprecated in 3.2.
Perhaps I am missing something - but the IDocumentProvider protocol already defines a life-cycle (connect / disconnect) and both AbstractDocumentProvider and TextFileDocumentProvider implement a reference counting scheme. Couldn't you use this to do what you want?
Yes, I did this and ran into the problem that the document was used after the document provider refcount went to 0. See also bug #65211, esp. comment #2: > Please be aware that deconstructing the document on disconnect is dangerous. > IDocumentProvider does not specify that a document once obtained from the > provider may become invalid without notification. The same is true for > IDocument. IDocument does not define a live cycle or predicates that tell a > client whether a document is deconstructed or disposed. Thus, any code that > does not care about the life cycle of specific IDocument implementations is > valid code. The changes I made can not be expected in general. It's just > courtesy. This is certainly true and it clearly expresses what is missing: a life-cycle for IDocument.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
