Subject: [AAA-WG]: RE: API, latest draft

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Mon, 23 Apr 2001 13:37:24 -0500

> >I'm not opposed to having separate configuration files, or 
> separate command 
> dictionaries, as long as the library knows about all of them, 
> and is told about 
> them only once.  If we could setup all of the dictionaries at 
> initialization 
> time (while still allowing for runtime updates to the 
> dictionaries), it would 
> probably be even simpler for the application.  
> 
> I think it would probably be easier in that case to just have a single
> command file. The whole point of having separate files is so that
> separate applications that don't know about each other can set up
> their command sets. This purpose would be defeated by requiring all
> the command sets to be registered at initialization time.

Alrighty, sounds good to me.

> >
> >Would it be possible to use some term other than "session" 
> for methods like 
> startSession(), etc.?  The overloading of this term is 
> responsible for quite a 
> bit of confusion (on my part), I seem to always get this 
> confused with the 
> "User" sessions described in 11.0 of the Base draft. 
> 
> The sessions managed by the session manager *are* exactly
> the user sessions in Chapter 11.0 of the Base draft. The only 
> difference is
> that they are being identified in the VM by a small integer 
> identifer rather
> than a session name. In fact, in the latest draft of the API, 
> there is even a 
> method,  SessionManager.getNetworkSessionId(), that is used 
> to get the Section 
> 11.2 network session identifier corresponding to a Diameter 
> User session.

Okay.  I got confused because I was trying to think of a case where you
would call startSession() infrequently (and thus would provide similar
dictionaries infrequently).  I assumed that maybe session was being used in
the sense of "Session == Transport Connection".  I'm back on track now.

...
> 
> >You have answered my question on this already, but I'll 
> clarify what I was 
> trying to get across.  From the library's perspective, there 
> must be some 
> fundamental correlation between an AVP and its code.  Its 
> code is the only key 
> that the library should really care about (all others are a 
> usability bonus), as 
> this will be a required component of parsing AVPs (and 
> Commands, for that 
> matter).  As you can see above, I thought that there were 
> distinct AVP and 
> command dictionary files, and the AVP dictionary had been 
> omitted, so I saw no 
> way for the library to get the information that it needed to 
> resolve an AVP from 
> its code.  The issue is moot now.
> 
> But I still think you have made a point. The spec currently requires
> the AVPDescriptor dictionary for a command to be indexed by the
> AVP name. As you have pointed out, it would be better to index
> it by code, so that it can be retrieved with a single hash when
> parsing a command. The command dictionary is already defined so
> that it can be indexed by code (actually, the interface is a method
> so it can be indexed however you want, but by code would probably
> be the most efficient).

Ok, sounds good.

-Brian