Re: Design help...an explosion of interfaces......
From: Mark Nicholls (Nicholls.Mark_at_mtvne.com)
Date: 09/03/04
- Next message: Mark Nicholls: "Re: Design help...an explosion of interfaces......"
- Previous message: Mark Nicholls: "Re: Design help...an explosion of interfaces......"
- In reply to: Daniel T.: "Re: Design help...an explosion of interfaces......"
- Next in thread: Daniel T.: "Re: Design help...an explosion of interfaces......"
- Reply: Daniel T.: "Re: Design help...an explosion of interfaces......"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 3 Sep 2004 02:09:22 -0700
> > >
> > > > class CAcknowledgedPipe : IPipe
> > > > {
> > > > ...
> > > > }
> > > >
> > > > class CAcknowledgedPipeWriter : IPipeWriter
> > > > {
> > > > IPipeFactory returnPipeFactory;
> > > > IPipeWriter innerWriter;
> > > > TimeSpan timeToBeAcknowledged;
> > > >
> > > > void Send(object message)
> > > > {
> > > > IPipe returnPipe = returnPipeFactory.CreateNewPipe();
> > > > IPipeReader returnReader = returnPipe.CreateNewReader();
> > > > returnReader.Enable(); // *1
> > > >
> > > > CMessageEnvelope envelope = new
> > > > CMessageEnvelope(message,returnPipe);
> > > >
> > > > innerWriter.Send(envelope);
> > > >
> > > > }
> > > > }
> > > >
> > > > now note returnReader.Enable() is asynchronous, I cannot say when it
> > > > actually happens (maybe this is a solution? i.e. only send the message
> > > > after we know the reader is enabled, but note we would not have to do
> > > > this if the pipe were buffered.
> > > >
> > > >
> > > > class CAcknowledgedPipeReader : IPipeReader
> > > > {
> > > > readonly IWormholeReader innerReader;
> > > >
> > > > void RecieveMessage(object message)
> > > > {
> > > > CMessageEnvelope envelope = (CMessageEnvelope)message;
> > > > IPipe returnPipe = envelope.GetReturnPipe();
> > > > IPipeWriter returnPipeWriter = returnPipe.CreateNewWriter();
> > > > returnPipeWriter.Send(new CAcknowledge()); // *2
> > > > ..... etc .....
> > > > }
> > > > }
> > > >
> > > > so we have a race condition if we get to *2 before *1 is complete the
> > > > acknowledgement may well be missed.
> > >
> > > Unfortunatly, you put '... etc ...' in the single most important spot in
> > > the example! If the Send fails, what must the client do differently
> > > based on the exact sub-type of PipeWriter?
> >
> > It depends what you mean by 'fail'. If you mean be sent to a pipe,
> > then really it can't fail.
> >
> > If you mean be recieved by a reciever then you don't know. If the pipe
> > is buffered, then the message is guarenteed to get to it and be there
> > until someone reads it. If it's unbuffered then it simply disappears
> > into the ether......thus it is important whether the return channel is
> > buffered or not.
>
> But how is important to the client? What must the client do differently
> in the two contexts? Again, you keep talking about what the server may
> or may not do, what I'm trying to get you to discuss is what the client
> does.
>
The client code (which in the case is the implementation of
AckPipeWriter) demands that it's PipeReader is ready to recieve any
anknowledgement before that acknowledgement is sent i.e. no race.
OK, maybe I maybe see where you going, but I'm not sure I buy it....
The client of the client demands that a message will be considered
'sent' if there is no error raised by the pipewriter....in this pure
DbC sense then the whether the pipe is buffered or not does not matter
(oh dear this reminds me of my problem with the Equals contract that I
considered useless)....
If the return pipe is implemented by a unbuffered pipe the
implementation is intrinsically likely to fail, if the return pipe is
buffered then there should be no reason (given the assumptions
contracted by the timeout i.e. that the timeout defines a 'reasonable'
time that the a reply should arrive), that it should fail.
So really the client of the Acknowledged implementation, given a
buffered implementation should expect and exception....of the
Acknowledged implementation, given an unbuffered implementation should
expect an 'error'.
i.e. the contracts are subtly different.
>
> > > > So say I have;
> > > >
> > > > Persistable
> > > > Volatile
> > > > Buffered
> > > > Unbuffered
> > > > Binary
> > > > Text
> > > > Multicast
> > > > Singlecast
> > > > Synchronous
> > > > Asynchronous
> > > > Transactional
> > > > etc
> > > >
> > > > in my current solution I would end up with 11*10*9.....*2*1 sets of
> > > > interfaces = bad.
> > >
> > > Given the list above, I only see 11 interfaces, not 11*10*9...*2*1...
> >
> > Well in theory I could want it to be Binary, Synchronous and
> > Buffered.....
>
> So, you still only have 11 interfaces...
>
> class BSBPipe : public Binary, public Synchronous, public Buffered
> {
> };
>
> The above is a class that implements 3 interfaces, it isn't a new
> interface.
- Next message: Mark Nicholls: "Re: Design help...an explosion of interfaces......"
- Previous message: Mark Nicholls: "Re: Design help...an explosion of interfaces......"
- In reply to: Daniel T.: "Re: Design help...an explosion of interfaces......"
- Next in thread: Daniel T.: "Re: Design help...an explosion of interfaces......"
- Reply: Daniel T.: "Re: Design help...an explosion of interfaces......"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
