No subject

Sun May 18 13:48:07 2003
Return-Path: xorp-cvs-admin@icir.org
Delivery-Date: Sun, 18 May 2003 13:49:03 -0700
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
	by tigger.icir.org (8.12.8p1/8.12.3) with ESMTP id h4IKn3Kd092197
	for <atanu@tigger.icir.org>; Sun, 18 May 2003 13:49:03 -0700 (PDT)
	(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11])
	by wyvern.icir.org (8.12.8p1/8.12.3) with ESMTP id h4IKn2DD025937
	for <atanu@icir.org>; Sun, 18 May 2003 13:49:02 -0700 (PDT)
	(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (localhost [127.0.0.1])
	by fruitcake.icsi.Berkeley.EDU (8.12.9/8.12.9) with ESMTP id h4IKn2KJ020171;
	Sun, 18 May 2003 13:49:02 -0700 (PDT)
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
	by fruitcake.icsi.Berkeley.EDU (8.12.9/8.12.9) with ESMTP id h4IKm7KJ020156
	for <xorp-cvs@icsi.berkeley.edu>; Sun, 18 May 2003 13:48:07 -0700 (PDT)
Received: from possum.icir.org (possum.icir.org [192.150.187.67])
	by wyvern.icir.org (8.12.8p1/8.12.3) with ESMTP id h4IKm7DD025933;
	Sun, 18 May 2003 13:48:07 -0700 (PDT)
	(envelope-from pavlin@possum.icir.org)
Received: from possum.icir.org (localhost [127.0.0.1])
	by possum.icir.org (8.12.8p1/8.12.3) with ESMTP id h4IKm7c1048191;
	Sun, 18 May 2003 13:48:07 -0700 (PDT)
	(envelope-from pavlin@possum.icir.org)
Message-Id: <200305182048.h4IKm7c1048191@possum.icir.org>
To: Mark Handley <mjh@icir.org>
cc: pavlin@icir.org, xorp-cvs@icir.org
Subject: Re: [Xorp-cvs] XORP cvs commit: xorp/libproto/ proto_unit.cc 
In-Reply-To: Message from Mark Handley <mjh@icir.org> 
   of "Sat, 17 May 2003 20:32:47 PDT." <50461.1053228767@vulture.icir.org> 
Date: Sun, 18 May 2003 13:48:07 -0700
From: Pavlin Radoslavov <pavlin@icir.org>
Sender: xorp-cvs-admin@icir.org
Errors-To: xorp-cvs-admin@icir.org
X-BeenThere: xorp-cvs@icir.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:xorp-cvs-request@icir.org?subject=help>
List-Post: <mailto:xorp-cvs@icir.org>
List-Subscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
	<mailto:xorp-cvs-request@icir.org?subject=subscribe>
List-Id: Mailing list for XORP CVS commit messages <xorp-cvs.icir.org>
List-Unsubscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
	<mailto:xorp-cvs-request@icir.org?subject=unsubscribe>

> 
> >	Note to ourselves: a number of target names
> >	("fea", "bgp", "rib", "ospf" and probably few more) are hardcoded
> >	in a number of places, which is a bad style.
> 
> Hmm.  I don't have a problem with the default name of the rib xrl
> router being "rib", and BGP talking explicitly to the "rib" target.
> Now, what should happen is that BGP registers interest in targets
> called "rib", the finder tells BGP about a particular instance of this
> target, and then BGP only talks to this specific instance.  But this
> requires a finder interface that isn't finished yet.
> 
> But if you're saying the the rib should under some circumstances call
> it's XRL router "foobar" and BGP should somehow learn that the RIB is
> called foobar today, then I think this is perhaps useful testing
> functionality, but shouldn't normally be done.  
> 
> One of the good things about XRLs in our architecture is that the
> target names are a fixed point, at least for singleton processes.
> This means you can write scripts or monitoring processes or whatever
> that can work without needing an additional level of indirection
> beyond that already provided by the finder.  This is kind of like
> well-known ports with TCP: yes, you can run an SMTP server on another
> port than 25, but many people who you'd like to talk to you won't be
> able to find you.
> 
> So, I don't think it's bad style to use and depend to a large degree
> on well-known target names.  But it probably should be possible to
> override them if you really want to do so.

In general, I dislike hardcoding of names, constants, etc.

As a startup, I was thinking about something very simple. Instead of
sending XRLs like
  send_foo("fea", ...)

use
  send_foo(fea_target_name(), ...)

(or sth. like that)

where fea_target_name() initially could be just a simple function
that returns string "fea".
Later on this function could be modified to obtain the target name
from the finder for example (or to do anything else we may want to
do with target names).

Regards,
Pavlin
_______________________________________________
Xorp-cvs mailing list
Xorp-cvs@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs