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/09/22 01:25:37 UTC

[jira] Created: (DIRSEDA-12) Allow encoder/decoder stage bypass

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIRSEDA-12

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIRSEDA-12
    Summary: Allow encoder/decoder stage bypass
       Type: New Feature

     Status: Open
   Priority: Major

    Project: Seda Framework

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Tue, 21 Sep 2004 4:24 PM
    Updated: Tue, 21 Sep 2004 4:24 PM

Description:
After some of our conversations regarding rerouting events and making the routing a bit more sophisticated I think we can handle special protocols that can bypass the encode or decode stages.  Some may not need these stages at all and it makes sense to enable them to bypass these operations.  The code of getting the asynchronous decode/encode operation to take place when the codec operation is not required is a waste. 


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

If you think it was sent incorrectly contact one of the administrators:
   http://issues.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


Re: [jira] Created: (DIRSEDA-12) Allow encoder/decoder stage bypass

Posted by Trustin Lee <tr...@gmail.com>.
DefaultEventRouter needs to be able to route events dynamically by
their underlying transport types (udp, tcp, and pipe).

But there is another point we have to take care of.  Let's assume
there are two services in the server: SMTP service and SPAM Filter
service, and they both accepts TCP/IP connections and PIPE
connections.  There are three possible cases:

1. SMTP Service queries SPAM Filter Service if the message is spam or not.

MTA (via TCP/IP) -> InputManager -> Encoder -> SMTP -> SPAMFilter ->
SMTP -> Decoder -> OutputManager

2. SPAM Filter Service sends an e-mail which contains a statistics
report to administrator using SMTP Service.

SPAMFilter -> SMTP -> remote SMTP -> admin's mailbox

3. SPAM Filter Service accepts SPAM checker clients' connections and
processes their requests.

SPAMChecker (via TCP/IP) -> InputManager -> Encoder -> SPAMFilter ->
Decoder -> OutputManager

The important issues are:

1. SMTP Service works both as a server and as a client.  SEDA might be
useless if it does not provide client side feature because no one will
not mess up with both event and stream model.

2. Routing between SMTP and SPAMFilter is very dynamic, and it becomes
more and more complex if services such as POP3 with DRAC support or
integrated authentication service is involved.  Routing instruction
will get very complex and cannot be determined easily just using
transport types.


On Tue, 21 Sep 2004 16:25:37 -0700 (PDT), jira@apache.org
<ji...@apache.org> wrote:
> Message:
> 
>   A new issue has been created in JIRA.
> 
> ---------------------------------------------------------------------
> View the issue:
>   http://issues.apache.org/jira/browse/DIRSEDA-12
> 
> Here is an overview of the issue:
> ---------------------------------------------------------------------
>         Key: DIRSEDA-12
>     Summary: Allow encoder/decoder stage bypass
>        Type: New Feature
> 
>      Status: Open
>    Priority: Major
> 
>     Project: Seda Framework
> 
>    Assignee: Alex Karasulu
>    Reporter: Alex Karasulu
> 
>     Created: Tue, 21 Sep 2004 4:24 PM
>     Updated: Tue, 21 Sep 2004 4:24 PM
> 
> Description:
> After some of our conversations regarding rerouting events and making the routing a bit more sophisticated I think we can handle special protocols that can bypass the encode or decode stages.  Some may not need these stages at all and it makes sense to enable them to bypass these operations.  The code of getting the asynchronous decode/encode operation to take place when the codec operation is not required is a waste.
> 
> ---------------------------------------------------------------------
> JIRA INFORMATION:
> This message is automatically generated by JIRA.
> 
> If you think it was sent incorrectly contact one of the administrators:
>    http://issues.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
> 
> 



-- 
what we call human nature in actually is human habit
--
http://gleamynode.net/

[jira] Assigned: (DIRSEDA-12) Allow encoder/decoder stage bypass

Posted by ji...@apache.org.
Message:

   The following issue has been re-assigned.

   Assignee: Trustin Lee (mailto:trustin@gmail.com)
---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIRSEDA-12

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIRSEDA-12
    Summary: Allow encoder/decoder stage bypass
       Type: New Feature

     Status: Open
   Priority: Major

    Project: Seda Framework

   Assignee: Trustin Lee
   Reporter: Alex Karasulu

    Created: Tue, 21 Sep 2004 4:24 PM
    Updated: Sat, 23 Oct 2004 12:52 PM

Description:
After some of our conversations regarding rerouting events and making the routing a bit more sophisticated I think we can handle special protocols that can bypass the encode or decode stages.  Some may not need these stages at all and it makes sense to enable them to bypass these operations.  The code of getting the asynchronous decode/encode operation to take place when the codec operation is not required is a waste. 


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

If you think it was sent incorrectly contact one of the administrators:
   http://issues.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