james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Zakula <tonyzak...@gmail.com>
Subject Re: Headless mail renderer
Date Fri, 13 May 2011 14:02:40 GMT
Hi Eric,

> We've got also the apache-extras [1] which is mercurial (hosted by google
> for addons to apache projects).

That good.  I will check it out.  I prefer mercurial.

> I was wondering if the parser can be used without the full myna server. I
> mean, we simply need to parse mail, not to configure a full server with
> users,... ([2]).

The core Java part of Myna to run the JS is only 4 Java classes to
wrap the Mozilla Rhino runtime.  All of the rest of the functionality
is provided via JavaScript.  I will carbon copy the main developer of
Myna on this message, but I am pretty sure we can create a trimmed
down version very easily.  Worst case scenario if you could not
integrate it, a Host object for Rhino could be written or Myna's could
be tweaked.  I do reuse some JavaScript Myna libraries, but that could
be dropped in anywhere.

> Also, is the parser component packaged as a maven module to be easily used
> as dependency somewhere else?

Ah well, I said it was rough around the edges.  :-)  My use case
scenario right now is to drop this on a server running a commercial
mail server to be an API gateway to web applications to specialized
functionality.  A bridge to the commercial mail server so to speak.
It was a project I am working on for a client specific to their specs.
 This tiny lightweight runtime allows me drop this on a server and
have have a bridge to that system.  When I make updates, I pull all
the new JS code with Mercurial to all the servers.  The project is not
complete either.  Just the parsing and a couple of API calls so far.
So that kind of stuff will be up to you.

> Whatever the response to the 2 above questions, feel free to push it where
> you like. I will look at it :)

Kind of let me know what you think about the above to help me package
it, but also make sure you are still interested.



> Tks,
> - Eric
> [1] http://code.google.com/a/apache-extras.org/hosting/
> [2] http://www.mynajs.org/site/article/MynaPermissionsAdministrator.ejs
> On 13/05/2011 01:51, Tony Zakula wrote:
>> Hi Eric,
>> JavaScript is also extremely flexible.  With Rhino, you get the full
>> power of Java plus a lot of flexibility.
>> What is the preferred spot of release?  Github, Bitbuckit, or is there
>> another?
>> Tony
>> On Thu, May 12, 2011 at 8:19 AM, Eric Charles<eric@apache.org>  wrote:
>>> Hi Tony,
>>> Javascript in james server would be a primeur.
>>> But why not... there is more and more JS "on the other side" (thinking to
>>> Node.js...). I'm using today Jackson to manipulate JSON in Java, but
>>> Javascript has a more natural fit, so I understand why you choose it.
>>> We will start around end-May with MAILBOX-44, but there today no
>>> discussions/decisions on the chosen format to persist mail.
>>> I would say "don't hurry, don't put pressure on you, and keep us updated
>>> when you think to release it" :)
>>> Tks,
>>> - Eric
>>> On 12/05/2011 14:35, Tony Zakula wrote:
>>>> Hi Eric,
>>>> I would be more than happy to release the code now even though it is
>>>> not entirely finished if you are interested.  The parsing part is
>>>> pretty good, and I am using it in a production project right now.  I
>>>> am not sure it will fit your bill though as I am using it on a mail
>>>> server to do message list bounce processing.  Although I write Java
>>>> code for a living, I wanted to make it easy to modify this utility on
>>>> a running server so I used an open source project I contribute to at
>>>> Mynajs.org which is built on top of the Mozilla Rhino project.  I use
>>>> Mime4J, but my code is written in JavaScript.
>>>> I would be more than happy to release the code now if you are
>>>> interested.
>>>> Please let me know.
>>>> Thanks!
>>>> Tony
>>>> On Wed, May 11, 2011 at 11:21 PM, Eric Charles<eric@apache.org>
>>>>  wrote:
>>>>> Hi Tony,
>>>>> We are starting to work on MAILBOX-44 "Design and implement a
>>>>> distributed
>>>>> mailbox using Hadoop" [1]
>>>>> We will need to store the mail in hadoop and the JSON format (in avro
>>>>> file)
>>>>> may be a option.
>>>>> You said you are "still polishing for release" your JSON transformer.
>>>>> Have you got any plan to release it in opensource so we could use it
>>>>> Tks,
>>>>> Eric
>>>>> [1] https://issues.apache.org/jira/browse/MAILBOX-44
>>>>> On 10/05/2011 10:00, Robert Burrell Donkin wrote:
>>>>>> On Sun, May 8, 2011 at 2:44 PM, Tony Zakula<tonyzakula@gmail.com>
>>>>>>  wrote:
>>>>>>> Not sure on where the project leaders want to go,
>>>>>> Projects are community led here at Apache (see eg [1][2][3][4]).
>>>>>> there's development interest from the community and it's in scope
>>>>>> the project, then that's a direction the code will move in.
>>>>>>> but I think being
>>>>>>> able to store messages in different formats to be able to plugin
>>>>>>> systems would be great.  Instead of each person writing their
>>>>>>> parser, most people would just plugin the larger piece to their
>>>>>>> system
>>>>>>> and start there.
>>>>>> +1
>>>>>> This vision seems to fit with the work over at Tika [5] and Lucene
>>>>>> [6].
>>>>>>> I did not see where you specified what you are thinking about
>>>>>>> summer.  Is that a link somewhere yet?
>>>>>> The mailing lists (see [7] and eg [8]) are the primary tools we use
>>>>>> here at Apache. Stuff only tends to get written down later, if at
>>>>>> We've been throwing ideas around on the lists, hoping that people
>>>>>> might pick some of them up and run with them ;-)
>>>>>> Robert
>>>>>> [1] http://www.apache.org/foundation/how-it-works.html
>>>>>> [2] http://www.apache.org/foundation/getinvolved.html
>>>>>> [3] http://jakarta.apache.org/site/contributing.html
>>>>>> [4] http://www.apache.org/dev/contributors.html
>>>>>> [5] http://tika.apache.org/
>>>>>> [6] http://lucene.apache.org/
>>>>>> [7] http://www.apache.org/dev/#mail
>>>>>> [8] http://www.apache.org/dev/contrib-email-tips.html

View raw message