You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by ji...@apache.org on 2004/03/05 04:52:32 UTC

[jira] Closed: (DIR-24) Design Eve's decoder service interface

Message:

   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:

http://cvs.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/eve/frontend/decoder/spi/src/java/org/apache/eve/decoder/DecoderManager.java?rev=6991&root=Apache-SVN&view=markup
---------------------------------------------------------------------
View the issue:
  http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=DIR-24

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
 Components: 
             Eve
             Snickers

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

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

Description:
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.  



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira