Fwd: Issues on Umit while identifying paths in a portable manner

[Diman Todorov <diman.todorov () chello at>]

i guess the cc's of that one were broken

Begin forwarded message:

> From: "João Medeiros" <ignotus21 () gmail com>
> Date: 07. August 2007 15:45:08 GMT+02:00
> To: "Diman Todorov" <diman.todorov () chello at>
> Subject: Re: Issues on Umit while identifying paths in a portable  
> manner
>
> Hi friends,
>
>     I think that something like linux kernel .config file system is a
> good choice. Giving to the user the opportunity to load the options
> from previous (or other) version. Whenever possible is a good pratice
> the creation of a structure that make this task more easy. Maybe, an
> application to compare two verions of Umit config file and select the
> more convenient options to create a third file is a way to solve
> problems with incompatible versions.
>
> Att, João Paulo de Souza Medeiros.
>
> On 8/7/07, Diman Todorov <diman.todorov () chello at> wrote:
> > On 07.08.2007, at 13:37, Adriano Monteiro wrote:
> > > Another problem that exists on Umit, and probably exists on most  
> > > open
> > > source projects, is that some configuration files may get old and  
> > > out
> > > of date. Installing new versions of Umit would require the update or
> > > replacement of the old files. The last approach is the better one  
> > > for
> > > developers: there is no such thing as "rm -rf ~/.umit" and  
> > > recreate it
> > > again using the new configuration templates. But,  using this  
> > > refined
> > > technique, users will lost their target list, options added to
> > > options.xml, profiles, umit preferences, and a lot more. The other
> > > approach (updating the config files) is better for users, but can  
> > > turn
> > > into a nightmare to maintain, mainly after several updates.
> >
> > that's a problem which exists not only for oss projects but for any
> > project which needs to access persistent data. Contrary to widespread
> > belief, the problem is not remedied by using xml or even a
> > persistence framework. There are basically only two things that
> > really help. The first one is to think thrice about your data model.
> > Try to keep your config files as generic as possible. The second is
> > to keep things who's syntax changes often separate from things that
> > have a stable structure. It is preferable that parts which require
> > heavy user interaction, like their scan profiles, don't change too
> > heavily or too often. If you do change the syntax for storing a
> > user's carefully crafted profiles, make sure you provide a script
> > which will convert their old config file to the new syntax.
> > Automating the conversion is even better.
> >
> > cheers,
> > Diman
> >
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://SecLists.Org


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org