Hello folks, The history of development of Umit is really very interesting to us that come in this year, as Guilherme said.
When I spoke with Luis about the QuickSearch, I gave the option to upload the data into memory, only for him to know that this option exists and that can work well. :) When we need performance and large volume of data, is a good solution. But isn't our case. ;) On Fri, Aug 29, 2008 at 3:41 AM, Adriano Marques <[EMAIL PROTECTED]> wrote: > 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? I fully agree. Recreate the xml definitely wasn't a good idea. > 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. Good observation, Adriano. This is a situation that often occurs. The process must be independent of the user. In that case, we have guarantee that the data will be there. When we work with files that need to be loaded and that have important data, it is good that they're in two places. Work with files is generally faster than database. One option is to save the scans in ~/.umit/scans/ as suggested by Guilherme, and also continue saving in the database. So we could work with scan data from a considerable performance, and maintaining the data in two different locations. Xml be in the ~/.umit/scans/ being loaded from the database. Thus avoid the problem raised by Adriano. For the QuickSearch, I'm still forming my opinion on how best to store the data. Working with files have more performance, as I said, in compensation working with the database, we can take their features already ready, as Adriano said. What you think about this point? Best, -- Daniel Cassiano _____________________________ Page: http://danielcassiano.net/ http://www.umitproject.org/ http://www.apontador.com.br/ ------------------------------------------------------------------------- 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
