[platform-vcm-dev] Questions on validateEdit/validateSave

[Kevin_McGuire@xxxxxxx]

Some questions and comments, with my interpretation of the correct answer, 
open to discussion.

Kevin

--------------

Q - In the case that multiple files are passed to validateEdit(), if all 
files
cannot be made writeable, must all files be restored to their state before
validateEdit() was called?  I assume not and a multi-status can be 
returned
with per-file status.

A - Correct, its up to the provider to determine how he wants to handle 
the partial failure case.  You could choose to return ! OK for all, or a 
multistatus with OK for some and ! OK for others.

--------------

Q - If the n'th file cannot be made writeable, should the
CM provider continue on to file 'n + 1'... or should it give up at the 
first
failure (or should the behavior be left up to the CM provider)?  If the
CM provider gives up partway through, how should that be reflected in the
status return?

A - It's be up to the provider. In that case, its also up to the provider 
to decide whether partial failure implies failure on the rest. I would 
assume that you would probably want to return !OK for the others which are 
unchecked.  As a rule, I assume that "OK==checkedout" and "!OK==couldn't 
checkout". If you give up early, then the remaining files remain 
uncheckedout, so !OK seems what you want.  The key here is that the reason 
someone gave you all the files together in one call was because they were 
somehow related, for example JDT refactoring.  The reason then that you 
care about interpreting partial failure as total failure is to ensure that 
the intergrity of those interdependent changes are preserved.  However, 
since we don't yet have anyone calling with more than one file, its hard 
to verify.

--------------

Q - Since the caller to validateEdit() must handle error notification 
(since
'context' may be null), does that imply that the implementor of
validateEdit() should not provide error feedback to the user (if 
possible)?

A - Good question, its one of my open ones.  I don't understand who should 
handle notification.  On the one hand you want the provider to since they 
have the most information available.  But in the case of no shell, the 
provider can't do much, but it seems neither can the caller.  I also don't 
like a story that says if you have a shell the provider prompts and if you 
don't the caller does.  If you didn't have a shell, would you (the 
provider) have other appropriate mean to notify, e.g. a provider specific 
log?  I suppose in the worst case you could at least write to the error 
log.

--------------

C - It's worth noting that validateEdit() could result in an updated file
[i.e. the contents changed in the process of servicing the 
validateEdit()].
Editors should be prepared for this and handle this case accordingly.

A - Agreed, otherwise changes could be lost. However, the specification 
doesn't say that this is a requirement on the part of the caller.  I would 
venture though that there is no point for the caller to initiate and 
examine the return value of validateEdit unless they are going to update 
their contents, since presumably otherwise we've lost most the of the 
benefit of validateEdit.  Comments?

--------------

C - It's also worth noting that validateEdit() is the perferred mechanism
over validateSave().  Just like validateEdit(), validateSave() could
result in an updated file.  The save operation that would immediately
follow would silently overwrite the differences between the version of the
file when editing began and the post-validateSave() version [if the
validateSave() had resulted in an updated file].  Thus, if at all 
possible,
all editors should use validateEdit() instead of counting on 
validateSave().

A- Agreed, although OTI of course can only speak for those editors we 
write.  The reality is that from a provider's perspective all they can 
rely on is validateSave.  If someone calls validateEdit then its a bonus.