in reply to Re: Reblessing
in thread Reblessing

You, dragonchild and the other monks voting for the Connection Model got me almost convinced.

But then I thought about the interface of the connection object and something struck me like lightning:

You are missing something! And that's because I made it not clear enough in the original question:

The types have serveral things in common, like 'show overall status' and the like, but do also several things different.

That wants to say:
I will ask every server the same questions, like 'what is your status?' or 'are you alive?'.
But I will also ask servers of different type different questions. E.g.:
A Replication Server will be asked 'is any of your connections down?' or 'is your stable device full?'.
And a database server will be asked 'is any of the databases full?' od 'is the cpu load very high?'.

I cannot ask all the questions through the connection object, because the connection object will know nothing about 'cpu load' or 'stable devices'.
I have to ask the server directly.

Or I have to reduce the question to 'tell me what you have to tell, I'll just show it'.

This would lead to a complete redesign, but since I just started, that wouldn't hurt much. :-)

I'll keep thinking about it and listening to you monks!

Replies are listed 'Best First'.
Re{3}: Reblessing
by dragonchild (Archbishop) on Jun 21, 2001 at 18:46 UTC
    A lot of this depends on how you're talking to your server. I'm assuming that you're connecting to the server over some IP connection (presumably TCP). That means you're passing messages back and forth through some socket. These messages have to be defined somewhere, either for you or by you.

    Now, if you're given a message set, you have to work within it (for the most part).

    If you're designing the message set, you have to take into account the various types of servers you know about, as well as the various types of servers you haven't even thought of. This means that your message set has to be flexible enough to handle expansions.

    I would recommend SNMP for this, but that's just me.

    Now, you're also making a very big conceptual error - you are not asking the connection objects anything. They simply are there to facilitate communication. They do two things:

    1. Take a message object and convert it to hexstream, then send it down the socket
    2. Be told to harvest a message from a socket, read the hexstream, and convert it to a message object.
    Oh, yes, there are two connection objects - one for the server and one for you.

    Now, from the client point of view, you are simply sending messages down a pipe, waiting for a response, then reading the response. You simply do not care what's on the other end(s). From each side's end, there's a magical place on the other side of the connection that magically sends messages back.

    Your client also has to know what to do if there's a given response. Now, this isn't saying that the client knows about a given server type ... not really. The client knows what to do if given a certain message. Think state machines.

    For example, the following sequence happens:

    1. You send a message saying "What is your type?"
    2. You receive a response saying "Replication"
    At this point, you would then send a series of messages, awaiting a response for each, to ask about connections and stable devices. If, on the other hand, you receive a response saying "Database", you would then ask about CPU load and the like.

    Your client has to be intelligent enough to know about different server types, just like a human has to be intelligent enough to ask the right questions when it encounters different situations. (If you think about it for a moment, you'll understand what I'm talking about.)

[reply]
Re: Re: Re: Reblessing
by Sherlock (Deacon) on Jun 21, 2001 at 19:21 UTC
    dragonchild hit on a very good point - it seems to me as if you're defining your own message set. If that's the case, it doesn't matter what you need to ask your server, you can define your own way of doing it. It's somewhat like defining your own network protocol. You make a request, your connection object interprets that request and sends it off to the server, then it simply funnels back the reply.

    I tried to point out in my first post:

    As long as the methods it uses are well thought-out...

    The connection object, along with your message set is, by no means, trivial. Far from it! With this sort of architecture, I tend to allow the "smarts" of the application to sit on the outer edge of the application, that being mostly within the client and somewhat within the connection object.

    But when you're creating this new message set for yourself, heed dragonchild's advice when he/she says that you need to account for server types that you haven't even thought of yet. Obviously, if you're considering the connection object approach, you're thinking about future expansion and adaptation of this project. That might very well include the use of a new type of server and your message set had better be able to adapt to that easily or your connection object's design is going to go down the tubes in a hurry.

    I'd spend some serious time contemplating the message set and where you want to put the "smarts" of this application.

    - Sherlock

    Skepticism is the source of knowledge as much as knowledge is the source of skepticism.
[reply]

      I've come into this discussion late, but there's something about the way you're (or rather, everyone) is phrasing this issue that's really confusing me.

      It seems to me that the question is whether:
      a) to have multiple possible server objects, and change the identity of an existing server object on the fly via reblessing
      b) to have a single connection object of fixed class, which points to a server object, and replace that server object on the fly by creating a new server object, rather than just reblessing the one that's already there

      In either case, the issue about defining the messages/protocol still comes into play, and would probably be a solved by something like having "generic" messages in a top-level Server class, while having more particular message sets defined in subclasses. (Or else a Message class heirarchy, inherited by different members of the Server heirarchy.) Resolving this issue seems to me to be orthogonal to the question of whether or not to choose a) or b).

      That question of reblessing seems to depend on how you need to treat the attributes of the existing server object. Do you want to pass them along to the next object, without any additional changes or tests, and without (I think) calling DESTROY when the original server object "goes away"? Then go ahead and rebless. Or would that be awful, say because the server subclasses have totally different attributes, and you can't just pass the attributes of a ServerX object into a ServerY? Then don't rebless.

      What am I missing here?

      -- Frag.

[reply]
Re (tilly) 3: Reblessing
by tilly (Archbishop) on Jun 21, 2001 at 21:35 UTC
[reply]

In Section Meditations