Hi, On Thu, Aug 28, 2008 at 4:10 AM, Adriano Marques <[EMAIL PROTECTED]> wrote: > Loading xml in memory is not reasonable. Nmap can *really* output some > *really* verbose and *really* huge xml files, which we wouldn't ever > mind to have then loaded in memory. That's why we moved from dom > parsing to sax.
This is true indeed. > > So, I'm not fully aware of how are things working on the proposed > umitdb, but it looks reasonable to mix the files with the database. We > could maybe keep a summary of the xml file content inside the > database, and decide to look inside the xml if the summary is > promissing based on the search term used. There is some confusion here, probably because of the similar umitdb and umitDB names (that is why I used to refer to umitdb-ng when I talked about mine). I think it is a good time to quickly talk about them, since people that joined umit this year may not be aware of them at all, so here it goes (although I may miss something since there has been some time since I looked at them): umitdb: - The current one used by umit - It keeps the entire nmap xml (with fields added by usr format) file in the database. - umit uses this, plus the completed scans in the open tabs, to search scans; umitDB: - The current one used by network inventory - Breaks the nmap xml output and store in database, optionally the entire xml file can be stored too; - doesn't include usr fields in the broken format. - network inventory uses this to tell differences between scans; - network inventory also uses this to search scans made; I dislike very much this option of storing the entire xml in the database, because we miss the point of using a database. Instead we should improve it and store all the other fields we intend to look for. This then introduces the problem of recreating the xml, so I would need to think about this before dropping support for storing the entire xml. > > Or, maybe I'm just wrong and we can keep the xml files inside the > database and search them from there directly. That is what umit does right now. > > Guilherme, do you remember what was the problems you were facing when > you decided to move the files outside the database? Maybe that could > help us make a better decision. > I think I never decided that, except if I forgot about it. It seems, somehow, Luis introduced some confusion here (or the db names were the reason). Me and Luis had a short talk in IRC, where he started talking about merging umitdb and umitDB. Then I told him how umitdb works, and why it could potentially stop existing. What I suggested was dropping umitdb and storing the scans in ~/.umitdb/scans/, for example. umitdb currently doesn't do much as a database, that is why this suggestion took place. > > Cheers! > > -- > Adriano Monteiro Marques > > http://adriano-marques.blogspot.com > http://umit.sourceforge.net > [EMAIL PROTECTED] > > "Don't stay in bed, unless you can make money in bed." - George Burns > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Umit-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/umit-devel > -- -- Guilherme H. Polo Goncalves ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
