Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Protocol Layer Zero, rewritten

Joel

Very happy to see you making a contribution. Looking forward to working 
with you and your colleagues at Compuware going forward.  


Regards

Mike Norman


-----Original Message-----
From: Joel.Hawkins [mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Friday, May 07, 2004 4:21 PM
To: hyades-dev
Subject: RE: [hyades-dev] Protocol Layer Zero, rewritten


Andrew, et. al.

I'm coming into the this discussion in the middle, as Compuware is just
finishing up the process of joining Eclipse, so please excuse me if I'm
covering ground you've already plowed. I've got a couple of questions 
about
your proposed protocol.

1. Are sessions intended to be full duplex in nature? I notice that the
server role does not appear to be able to initiate a DISCONNECT command. 
Is
the server always intended to play a passive role at layer 0? If not, 
then
the DISCONNECT command may want to pick up an optional  Reason 
Code/Message
pair.

2. Can a connection be refused for multiple reasons? If so, then the
CONNECTION_REFUSED payload could be represented as a repeating group in
order to save line turnarounds.

3. Has any thought been given to the internationalization repercussions 
of
adding message text to the base protocol? In other words, what
language/encoding will be standardized on for the messages? Perhaps the
preferred language settings could be propagated in the initial 
connection
request?

Again, my apologies if these are topics that have already been discussed 
and
decided on. I'm looking forward to more timely participation in the 
future!

Thanks,
Joel Hawkins
Compuware

-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx
[mailto:hyades-dev-admin@xxxxxxxxxxx]On Behalf Of Kaylor, Andrew
Sent: Thursday, May 06, 2004 8:11 PM
To: hyades-dev@xxxxxxxxxxx
Subject: RE: [hyades-dev] Protocol Layer Zero, rewritten


Kim,

Thanks for the feedback.  Below are some responses which may further the
discussion and should help other people who have yet to review the
document.

I think it is the right approach to look at this as independent of the
old design.  However, at a few places in the document I took the liberty
of assuming that the intended audience was familiar with the current
design and made some comments that weren't properly part of the
specification itself but were intended just to give some indication of
what I was thinking.  This is the meaning of the "expected" language in
the document.  Maybe that was a bit sloppy.  At this level, all the
connections should be entirely generic.

As far as the terminology (engine, server, etc.) the document reflects
the fact that I just didn't know what we're calling the component
formerly known as the RAC, so I waffled a bit.  In all cases
server=engine=RAC.  Sorry about that.  For clarity, I'll (tentatively)
call it the HCE below.

"Client" refers to the plugins running in the Eclipse environment that
are interfacing with the user, although I want to keep the "client"
concept a little more generic than that.  Basically, by "client" I mean
some opaque component that uses agents.

I do intend for the all communication between the client and the agents
to be brokered by the HCE.  So that connection is meant to be part of
the logic, not just the implementation.

The meaning of the server ID is best understood in terms of its usage in
the previous document I sent out, where it is used in the command
header.  The way these IDs are generated is also described there.  The
process ID is needed for object connecting via a named pipe in order to
determine security attributes.  Strictly speaking, it probably should be
part of the socket connect command.

You were correct in guessing that I omitted the connection ID from the
DISCONNECT and DISCONNECT_ACK commands because the connection ID is
implied.  I didn't want to build in the ability for one connection to
disconnect another.  The reason that the connection ID is included in
the CONNECTION_COMPLETE message is that the client or agent needs the
connection ID for other commands (as a self-identifier), but it must use
an ID generated by the HCE.  This ID is created in response to the
CONNECT commands.  Once again, the meaning of the connection ID is best
understood in terms of its use in the command header described in the
other document.  Sorry for the implicit cross referencing.

-Andy

-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx]
On Behalf Of Kim Coleman
Sent: Wednesday, May 05, 2004 7:09 PM
To: hyades-dev@xxxxxxxxxxx
Subject: Re: [hyades-dev] Protocol Layer Zero, rewritten






I tried to step back and evaluate Andy's proposal without dragging along
too much baggage from the current implementation. I hope that was the
right approach. It makes me ask questions I wouldn't ask if we're just
formalizing the current impl with some tweaks. Also, I just commented on
your most recent (shorter :-) proposal and haven't yet made it through
the
rest of longer document. IOU.

1. Architecture
This is a meta-issue. We haven't really defined the component
architecture
for the collection framework, so it makes it hard to talk consistently
and
unambiguously about things like who connects to who, who offers what
services, etc. I think everything we write during this effort could
benefit from defining some of the terms we're using. We talk about the
"engine", the "server", "client" and "agent", but none of this is
clearly
defined anywhere. For example:

-  What's encapsulated by the Hyades Collector Engine (or DCE :-). Is
this
whole framework of client (workbench)
   API's, RAC (or it's replacement) and agent interfaces? From Andy's
use
case diagrams, I think the answer
   is yes, but it might be worth defining somewhere.
- What do we mean by "server"? Is this the same as the engine?
- If engine != server, what is the "engine"?

Does a client semantically connect  to a server or to an agent? Is the
existence of the man-in-the-middle (i.e. RAServer) a required part of
the
HCE specification or an implementation detail? It affects the
terminology,
IMO.

I'm not trying to suggest that the burden for defining this should be
Andy's. But it would be helpful to know specifically what some of these
terms mean in Andy's document.

2. Usage of SOCKET_CONNECT & PIPE_CONNECT

There's verbage in the descriptions of these two message types to the
effect that only clients are "expected" to connect via sockets and only
agents are "expected" to connect via a pipe. We're either blurring the
line here between specification and implementation or we're being a
little
too wishy washy. :-)

Does the specification require that only clients use sockets and only
agents use pipes? If so, let's just say so. It doesn't preclude
loosening
the restriction at a future time.

I don't think we can straddle the fence - if I'm writing a client, it
doesn't help me to know that the underlying implementation *might*
support
a pipe connect.

Conversely, if we don't intend to restrict the usage, then we probably
shouldn't talk about "expectations" in the message definition.

We've mentioned clients & agents, but not servers in this discussion of
expectations. Yet servers are mentioned in the objec type discussion. If
we leave this verbage in about expected usage, we need to mention
servers
somewhere. How do they connect?

3. Object ID in  SOCKET_CONNECT & PIPE_CONNECT

I'm puzzled about the object id field. It is "not used for clients". Why
not? Why do I need to be able to identify an agent or server, but not a
client? Again, this feels like the current impl is influencing the
definition more than it should.

4. DISCONNECT & DISCONNECT_ACK

Neither of these messages has a payload. If I understand correctly,
DISCONNECT is a disconnect request from the connection initiator
(client,
agent, other server). Is there no need to identify the connection? Seems
like it should. If not, then why is a connecton id included in the
CONNECTION_COMPLETE message? I guess the connection is implicitly
identified by the pipe/socket it comes in on. But I still wonder in that
case why a conn id is used elsewhere in the messages.

Ditto with the ack. What disconnect am I acknowledging?

Or does the implied architecture limit you to a single connection?

5. Object id's and server id's

We're specifying that the object id for an agent is its pid. Is it
really
the pid or is the pid an impl of the requirement that it be a unique id?
Again, I'm nit picking because I'm trying to find the line between
specification and implementation.

If it is a unique id we're after, does the pid necessarily satisfy this
requirement? What if I have more than one agent running in the same
process? Does the architecture preclude this kind of implementation?
What
is the OID used for?

Where do server id's come from? How is the namespace of all server id's
managed?

-Kim

Kim Coleman
PurifyPlus Development
IBM Rational Software, Cupertino, CA
(408) 863-4094 (T/L 560)
kcoleman@xxxxxxxxxx

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev
_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev



The contents of this e-mail are intended for the named addressee only. 
It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or 
disclose
it to anyone else. If you received it in error please notify us 
immediately
and then destroy it. 

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev



Back to the top