[clam-devel] Changes to NetworkEditor

Fri Jul 16 07:22:57 PDT 2010

Hey guys, as you know I'm trying to call clamrefactor.py from NetworkEditor
but I've run into a problem. When I call the constructor of the class in the
module from C I get:
"No module named expat; use SimpleXMLTreeBuilder instead"

When I try to use the module directly with a Python script the constructor
works just fine, so I don't think it's an installation issue as google
suggests

I'll send you the code so you can reproduce the error. I'm running Ubuntu
10.04.
To compile the code just type 'make' and to run it " PYTHONPATH=`pwd` ./main
" otherwise the program won't find the module.

Thanks!

On Thu, Jul 1, 2010 at 6:01 PM, David García Garzón <
david.garcia at barcelonamedia.org> wrote:

>
>
> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20100716/dc8ce1c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clamrefactor.py
Type: text/x-python
Size: 13429 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20100716/dc8ce1c9/attachment-0004.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cxx
Type: text/x-c++src
Size: 1066 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20100716/dc8ce1c9/attachment-0004.cxx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 461 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20100716/dc8ce1c9/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.clamnetwork
Type: application/octet-stream
Size: 1116 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20100716/dc8ce1c9/attachment-0009.obj>