Re: [Agentx] Benefit of multiple sessions per sub-agent connection

[Julian Scheid <[e-mail]>]

Hi Randy,

thanks for your reply.

On Fri, Jul 2, 2010 at 9:42 AM, Randy Presuhn
<[e-mail]> wrote:
> Examples that come to mind are when the subagent is functioning as a
> gateway to some other subagent protocol, bridging to a transport
> protocol not supported by the master agent implementation, or both.
> I suppose it could come in handy with a connectionless subagent transport,
> but that seems to me to be a bit of a stretch.  There might be other uses,
> but I've been away from this stuff for a long time.

This makes sense. Since my implementation won't have to be used to
build a bridge or such, I think I'll implicitly open a singleton
session and hide the details from the user.

> There really isn't much reason to expose session ID in a subagent API.
> Assuming you have some kind of constructor that returns a session object,
> the session ID would be private data that only the library, and not the
> user code, would ever have to llok at.

Sure, but even when hiding the ID, exposing a session object
complicates the API slightly - now people have to interact with two
objects rather than one.  There'll be an additional call to create the
session and users will have to worry about things like the session
object becoming invalid when the connection is closed. Not that big of
a deal but if those details can be hidden, all the better.

> Not silly at all.  As I recall, this was a "borderline" feature of the protocol,
> dating from a time when lots of things other than AgentX were in use,
> and the need to be able to build ways to support legacy subagents was
> a real concern.

Thanks for explaining the rationale, much appreciated.

Julian