[clam-devel] Changes to NetworkEditor

[David García Garzón]

On Thursday 01 July 2010 00:17:56 Xavier Serra wrote:
> On Jun 30, 2010, at 11:18 PM, Natanael Olaiz wrote:
> 
> Hi,
> 
> El 06/30/2010 09:13 PM, Xavier Serra escribió:
> 
> On Jun 30, 2010, at 5:01 PM, David García Garzón wrote:
> 
> 
> On Monday 21 June 2010 17:14:57 Xavier Serra wrote:
> 
> 
> Hi guys,
> I'm Xavi Serra, an student at UPF doing his final project for CLAM with
> David.
> 
> We intend to extend the funcionality of the NetworkEditor. The first
> thing we are doing is to detect when a network file is outdated and
> automatically throw clamRefactor (asking permission to the user to do
> so).
> 
> [snip]
> 
> Xavier Serra
> 
> 
> Committed after some refactorings we did yesterday together. Now a dialog
> is shown on version mismatch and in the case of a network of an older
> version it gives you the option to upgrade the network by using
> clamrefactor before loading it. The upgrade is still dummy, but Xavi is
> already working on it.
> 
> Xavi, some screenshots would be helpful so that other developers can do
> comments on usability aspects. Could you put them on the wiki?
> 
> 
> 
> Done.
> 
> It would be great too if you guys could give some feedback about usability
> issues. I think the messages are now, after David's modification, more
> clear but I'd prefer more opinions.
> 
> 
> 
> The messages are clear to me.
> 
> But I have some questions:
> 
> 1- The clamVersion attribute did always existed on the clam network files? 
> (I cannot found it in the CHANGES log) If not, there are probably no clam
> networks so much outdated being used... but what would happens if it
> doesn't exist? From
> http://doc.trolltech.com/4.5/qxmlquery.html#evaluateTo-4 : "If output is
> null behavior is undefined."
> 
> 
> It didn't. Files without the attribute are treated as older file and thus,
> need conversion. David told me these files are pre-1.2 or so.


Indeed first versioned version was 1.3.1 (unreleased) so unversioned versions 
should be considered 1.3.0 or earlier.

> 2- What would be the behavior in case of different versions? I think that
> checking the version number is OK as a first test of possible conflict
> between releases, but the needed changes and the definitely tests should
> be done looking in a migrationScript file or something like that. How we
> would deal with the different migrationScripts that we have in the core
> and different plugins? We would include all of them in the NetworkEditor
> to make such a test?
> 
> 
> When NetworkEditor detects that a file is older it will throw clamRefactor.
> The idea is to have a migrationScript file with the steps needed to go
> from version to version and use that when calling clamRefactor

> 3- David: do you think that it would be difficult to put the interface to
> check the network version on the CLAM::XMLStorage class? I know that this
> improvement  and interface to  solve the version conflict is inherent to
> the NetworkEditor, but CLAM::XMLStorage would not be the ideal place to
> just check the version? Maybe returning diferent error codes on the
> Restore...

First approach was using XMLStorage to extract just the version in a double 
parsing like now, but that led us to some hard to solve problems. It's true 
that doing such a thing in the actual network loading would be more elegant it 
would need more insight from Xavi on the loading process. So i would left that 
for a future refactoring. Sorry for adding a new dependency but still is Qt.

Besides that, current cases are:
- Same, load as is
- Older, warn, update and load (default)
- Older, warn, load as is
- Older, warn, cancel
- Newer, warn, user cancels (default)
- Newer, warn, user load it as is

I am wondering whether, it is more usable that, in the case of older versions 
updating without asking. Something like:
- Same, load as is
- Older, update and load
- Newer, warn, user cancels (default)
- Newer, warn, user load it as is

Any way, while the update is not finished, i would keep update as an option.