GSoC 2008: netconf suggesion

[Andreas Louca]

I totally agree with you.

The problem is I don't really understand whats the ultimate target.

So lets recap, we want something that just works and completed fast in
order to provide some functionality up until a milestone of a first
release and get some feedback back to the project, after being
accepted in Debian lothy in August. At a later time (out of the scope
of GSoC), the netconf would be rewritten, in C/C++, laying down some
more extensive foundations, in order for netconf to be more
"mainstream".



On Thu, Mar 27, 2008 at 1:08 PM, Colin Alston <colin at thusa.co.za> wrote:
> On 27/03/2008 12:57 Andreas Louca wrote:
>  > What I meant it doesn't take a long time to define a few API calls,
>  > that would be a guideline for later.
>
>  Just to interject on that point.
>
>  It may seem "simple" to define a bunch of API calls but you have to
>  remember the whole point of an API. It's not something that can be
>  micro-managed well in parallel with development unless you have a very
>  very well defined structure.
>
>  The thing of primary importance is that your API components should
>  NEVER change. It can gain functionality but if you discover a function
>  should require more parameters or some such later on in the project,
>  if that API change causes an architectural shift then you have a
>  catastrophic problem.
>
>  So still I feel even a small Bridge API is not something to be taken
>  lightly. Considering the current netconf strategy is not necessarily a
>  throw-away prototype, you still need a plan and it needs to be well
>  executed - not rushed.
>
>  Regards,
>  --
>  Colin Alston <colin at thusa.co.za>
>  System Analyst, Linux & Internet Services
>  Thusa Business Support (Pty) Ltd
>
>  "Usually the protocol is this: I appoint someone for a task,
>  which they are not qualified to do.  Then, they have to fight
>  a bear if they don't want to do it." -- Glyph Lefkowitz
>
>