directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Closed: (DIR-24) Design Eve's decoder service interface
Date Fri, 05 Mar 2004 03:52:32 GMT

   The following issue has been closed.

   Resolver: Alex Karasulu
       Date: Thu, 4 Mar 2004 7:52 PM

I've made the appropriate proposals to the commons codec people and now have the final decoder
interface carved out.  Here it is:
View the issue:

Here is an overview of the issue:
        Key: DIR-24
    Summary: Design Eve's decoder service interface
       Type: New Feature

     Status: Closed
   Priority: Critical
 Resolution: FIXED

    Project: Directory

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Fri, 20 Feb 2004 8:48 AM
    Updated: Thu, 4 Mar 2004 7:52 PM

Do I start making front end stubs that model decoding in the 2 phases below?

  a). Decode binary to TLVs triggering TLV arrival events?
  b). TLV tree -> PDU data structure triggering complete Message 
      arrival events?

This would require two stages (components) in the server.  

Or instead should we just make the Decoder service interface a subsystem façade treating
the decoding process as a single atomic operation?  

Internally the decoder can be composed of more than one phase/stage but outside of the decoder
you don't notice this - it's encapsulated away.  Either way if this subsystem is to participate
it should leverage the event bus to couple its components.  As I write this I'm beginning
to realize that the façade based approach encapsulating and abstracting away the nature of
the implementation is best.  Because here we can plugin the standard blocking constructs and
use them until the event driven non-blocking decoder is ready.  

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message