Hi Guilherme! Thanks for your quick reply :)
> 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. At the time I wrote umitdb, I also thought it a waste of a lot of things to store the whole xml inside the database. But then, I faced the reallity: I needed to code something fast, because I was approaching the GSoC deadline. Also, at the time of the decision, I realised that storing the whole xml could be good for search performance, because we wouldn't have to care about parsing the xml and search for term, but that also would constrain our search capabilities. In the end, I decided that the search feature is not one of the most used features of Umit, and that for our purposes, we could live with these odds. But, I think that our reallity has changed a little bit, and now we have the time and heads to make a better decision now, based on the projects we intend to develop here. I'm pretty glad that now, Umit doesn't have only one head anymore, and that you guys have being helping the project a lot. Now, the project can rely on all of you to find it's way on success. So, returning to the main subject, I also thought that recreating the xml wasn't a good idea, because nmap xml can change with time, and we would need to follow it, fixing our parser and maybe constraining compatibility between umit and nmap. That is not what we need, right? Also, I think that keeping a database with reference to the real xml stored in a directory could bring us some issues, eg: user wants to make backup, and forget to save the xml files, user made the backup with xml and database, but then he failed to deploy the files in their respective correct places, dealing with exceptions for each case in umit code, etc. I'm not saying that we shouldn't go this way, I'm just considering some things that can possibly happen, so we can make a brainstorm here and come out with a better solution. Another option would be, break the file and save it in the database, so we can make use of the database capabilities, and save also the whole file in database, in another table to avoid performance constraints. This way, we could have everything in only one place, and we won't blame the database by storing only xml files on it. >> 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. Yes, that's what I meant, that perhaps we could keep what we currently have. That's an option also. > 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. Ok, no problem. We are here to get hid of the confusion then ;-) 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
