[clam-devel] Changes to NetworkEditor

David García Garzón david.garcia at upf.edu
Sun Jul 18 06:17:55 PDT 2010


Try with the attached Makefile which uses python-config to retrieve the 
compilation flags. It works quite well in ubuntu lucid.

David.

A Divendres 16 Juliol 2010 16:22:57, Xavier Serra Román va escriure:
> 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.

-- 
David García Garzón
(Work) david dot garcia at upf anotherdot edu
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: text/x-makefile
Size: 334 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20100718/a0dc1cb8/attachment-0004.bin>


More information about the clam-devel mailing list