Hi,
First, I would like thanks for clarification about umitdb and umitdb-ng :)
On Thu, Aug 28, 2008 at 1:18 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote:
> 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.
Well actually I think to made search Umit loads xml from database, and load
it with NmapParser to made search inside scan files.
>
>
> >
> > 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.
Yeap. We should decide if we will store files inside a folder (something
like you suggested ~/.umit/scans) or if we store all inside a database (with
modifications of course, I'm not talking about store a entire xml within
database.
>
>
> >
> > 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).
yeap. About first email I'm clarified, and in second I made confusion. I
wanted to say umitdb-ng. ( I like your acronym about new generation name,
sounds good :-D )
>
>
> 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.
I agree with your suggestion, as you said above is not good idea use a
database to store entire xml. By the way, about your other email
improvements on (quick)Search Windows, it would be a window more quickly and
easy to search scans ( following some conversation with Adriano and Cassiano
it will integrated on Quick Scan)
About auto-completion, when you search by target completion ip numbers, host
address, named of scans.
Why we will load all xml files and get a list of some parameters to made
auto-completion instead use something like "SELECT target FROM scans_someone
WHERE hosts_or_something = "elephants.org" ? :)
That's my point.
>
>
> >
> > 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
>
Cheers,
--
Luis A. Bastiao Silva
-------------------------------------------------------------------------
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
