the mca I am using is in the yahoo directory. so I am not proposing to put yahoo mca in the trunk. I do have a shippers mca that deals with ups, fedex, dhl.
BJ Freeman sent the following on 9/30/2008 7:43 PM: > [The point I was trying to make is that the decision of whether or not > an email is a Yahoo email has to be made *somewhere* - so why not keep > Yahoo-related code in one place? Your approach scatters the > Yahoo-related code.] > > to me putting email processing in the yahoo code is squattering the > email processing code. > > guess it is a matter of what should be where. to me it is a email till > it get dispatched. So I treat it as a email. > to me email processing, related to sorting belongs in the MCA. This > philosophy follows in mail servers as well, like james. > > then all the specific code for that email processing should be in the > related code, the email is dispatched to, like the parsing of the email. > > > > > > Adrian Crum sent the following on 9/30/2008 5:44 PM: >> Until someone is willing to to make those changes, you're stuck with the >> tools at hand. That's why I suggested moving your parsing logic to the >> processing logic you already have. >> >> Your example: >> >> If an email has a return path that contains "[EMAIL PROTECTED]" and/or (not >> sure which) the email is from "Yahoo" then it's a Yahoo email - send it to >> ProcessYahooEmailOrders. >> >> My suggestion: >> >> Send incoming email to ProcessYahooEmailOrders. If the email has a return >> path that contains "[EMAIL PROTECTED]" and/or the email is from "Yahoo" then >> it's a Yahoo email - continue processing. Else return. >> >> The point I was trying to make is that the decision of whether or not an >> email is a Yahoo email has to be made *somewhere* - so why not keep >> Yahoo-related code in one place? Your approach scatters the Yahoo-related >> code. >> >> -Adrian >> >> --- On Tue, 9/30/08, BJ Freeman <[EMAIL PROTECTED]> wrote: >> >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> Subject: Re: ServiceMcaCondition adding conditionals and multipline >>> conditions. >>> To: [email protected] >>> Date: Tuesday, September 30, 2008, 4:26 PM >>> just to recap my question had to do with modifying the >>> ServiceMcaCondition.java >>> to handle a contians operator and allowing more than one >>> condition for >>> fields and headers. >>> Nothing specific about the type of email like fedex or ups. >>> >>> >>> BJ Freeman sent the following on 9/30/2008 3:39 PM: >>>> #1 is to determine were to direct the specific email >>>> <mca >>> mail-rule-name="EmailOrdersRule"> >>>> <condition-header >>> header-name="Return-Path:" >>> operator="matches" >>>> >>> value="[EMAIL PROTECTED]"/> >>>> <condition-field >>> field-name="subject" >>> operator="not-contains" >>>> value="RE:"/> >>>> <condition-field >>> field-name="subject" operator="contains" >>>> value="Order*"/> >>>> <condition-field >>> field-name="from" operator="contains" >>>> value="Yahoo"/> >>>> <action >>> service="ProcessYahooEmailOrders" >>> mode="sync"/> >>>> </mca> >>>> >>>> that is my uncerstainding of mCA. >>>> otherwise why not just do a way with it? >>>> #2 not sure the function of #2 since that can be >>> filtered by the mca. >>>> Why bury the filter algorithms in code. isn't that >>> what MCA are for? >>>> #3is done with the MCA dispatch. and is more flexible >>> than burying it in >>>> code. >>>> >>>> Adrian Crum sent the following on 9/30/2008 3:23 PM: >>>>> From a design perspective, my preference would be >>> to have a good >>>>> separation of concern. Something like: >>>>> >>>>> 1. MCA triggers service call >>>>> 2. Service pre-parses mail - drops obvious rejects >>>>> 3. Service forwards mail to a processing chain: >>>>> >>>>> Pre-Parsed Mail -> Fedex Processor -> UPS >>> Processor -> Import Processor >>>>> -> etc. >>>>> >>>>> The disadvantage to having the parsing done in the >>> MCA XML code is you >>>>> end up cross-cutting code (spaghetti code). For >>> example, Fedex-specific >>>>> code would be in your Fedex process AND in the MCA >>> XML code. It would be >>>>> better to keep all Fedex code in one place. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> BJ Freeman wrote: >>>>>> if you look at the msg about checking for >>> duplicates in the user ML you >>>>>> can see that any thing that will take longer >>> will eventually clogs the >>>>>> system. >>>>>> Most of my clients have hundreds of emails >>> from shippers >>>>>> (fulfillment/dropshippers) and suppliers about >>> status of drop ship >>>>>> inventory. >>>>>> So I would like to make the process as >>> efficient as possible but having >>>>>> the mca get to the correct parsing. >>>>>> >>>>>> >>>>>> >>>>>> BJ Freeman sent the following on 9/30/2008 >>> 1:23 PM: >>>>>>> routines are in java. and meant to parse >>> the email. they never get put >>>>>>> in the communications event. >>>>>>> >>>>>>> Adrian Crum sent the following on >>> 9/30/2008 1:13 PM: >>>>>>>> What are the processes written in? Are >>> they services? If yes, then you >>>>>>>> could set up a service group and have >>> the email go from service to >>>>>>>> service - each service acting on the >>> email accordingly. >>>>>>>> -Adrian >>>>>>>> >>>>>>>> BJ Freeman wrote: >>>>>>>>> thanks >>>>>>>>> but I have many processes that are >>> based on the email subject and or >>>>>>>>> sender. Fedex notification, UPS >>> Notifications, Order of different >>>>>>>>> formats >>>>>>>>> Import routies, etc. >>>>>>>>> would like to do this in the mca >>> so I don't have to write this in java >>>>>>>>> code then do the same thing. >>>>>>>>> >>>>>>>>> Adrian Crum sent the following on >>> 9/30/2008 12:47 PM: >>>>>>>>>> The way I handled it here was >>> to have a simpler condition that >>>>>>>>>> sent the >>>>>>>>>> email into a processor that >>> did additional evaluations on the email. >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> BJ Freeman wrote: >>>>>>>>>>> if seemed pretty simple to >>> add the conditionals. >>>>>>>>>>> but looking a the decision >>> tree it looks like is an or'ed condition. >>>>>>>>>>> if I have two condition >>> for the same header or field and one of >>>>>>>>>>> them is >>>>>>>>>>> true then they will all be >>> true. >>>>>>>>>>> The question is, is >>> expanding the conditions to accept and and or >>>>>>>>>>> condition acceptable. this >>> would include a grouping of each >>>>>>>>>>> condition >>>>>>>>>>> like in an If statement. >>>>>>>>>>> >>>>>>>>>>> rationale: >>>>>>>>>>> a lot of emails have parts >>> of a field or header that needs to be >>>>>>>>>>> looked >>>>>>>>>>> at. for instance >>>>>>>>>>> subject: order #13950 from >>> yst-1309 >>>>>>>>>>> to parse you want >>>>>>>>>>> [contain order >>>>>>>>>>> and >>>>>>>>>>> contain yst] >>>>>>>>>>> or >>>>>>>>>>> not-contain Re: >>>>>>>>>>> >>>>>>>>>>> BTW any hints on how to >>> define a group of condition in the xsd would >>>>>>>>>>> help. >>>>>>>>>>> >>>>>>>>>>> >>>> >>>> >> >> >> >> >> > > > >
