[Bulk] Re: [Xorp-hackers] Some thoughts

[Patrick Preuss]

> -----Ursprüngliche Nachricht-----
> Von: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] Im >
> Auftrag von Mike Horn
> Gesendet: Montag, 7. November 2005 05:31
> An: 'Patrick Preuss'; xorp-hackers@xorp.org
> Betreff: RE: [Bulk] AW: [Xorp-hackers] Some thoughts

> Hi Patrick,

> In cases like ospf4 -> ospf and other configuration mappings, what if we
> developed a separate configuration converter for these types of
situations?
> I agree with Hasso that I would prefer to have the configuration
interpreted
> literally, exactly as it is in the configuration file, otherwise what you
> view in the configuration file will not match what you see in rtrmgr after
> the configuration is loaded.  Just my $0.02!

Yes you are right you will have a difference between startup and running
configuration, but in this case only until the point you save the config 
Then there will be the new values. To have a tool witch does this is a nice
idea, but how to deal with this? I think you can argue this or that way how
to do this, but from my point of view we should provide a way to deal with
this and not go the hard way, witch mean to drop the old once and maybe not
to start the system at all.

But from my point of view there must be a way to deal with such things,
maybe rewrite the config to the new values, or support both ways for some
time, so the users have the chance to do the things by them self. Because
some you will not have always the chance to change things in advance. The 
Reasons wary why you have not or can not do this, but you have the need to
upgrade the software for maintenance reason, so the software have the need
to deal with this. For example framework for rip witch deals with route
import and export, hope I remember correct, from my point of view we have
the need to deal with both ways for some time so the users have the chance
to update the configs, maybe the way could: 1.1 old way, 1.2 introduce the
new way, but support the old also and inform the user that this will be
obsolete in later releases, 1.3 drop the support for the old way. 


> -mike 

> 

patrick