On Fri, Nov 28, 2008 at 8:34 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> one my personal ambitions for the mailet 3 API is a broader interface >> that allows more than just RFC822 documents to be mailed. james >> already supports news (in an unintegrated fashion). i find myself >> increasingly seeing blogs as mail, wanted to be able to grab a feed >> and refer to it later. > > I guess you mean "blog posts" as "mail" and not "blogs" as "mail", right?
yep > And maybe "blog url" as "mail address" and "blog" as "mailbox"... yep :-) >> so, i'd like to add a feed fetcher to James (a bit like fetchpop) >> probably supported only by JCR initially (since that's what i'd like >> to use) with no processing integration as yet > > so you mean an input channel, not an output channel. input channel for now but mail output to Atom would be cool too (should be easy enough to create an adapter mailet) > I'm not sure what should the JAMES approach be wrt integration: do we > want to replicate Apache Camel? James already does some of what services buses like Camel can do. replacing the current spool manager with Camel would bring a lot of advantages. > What are the main differences between > what we'd like to do and what Camel already does? i've been thinking about this a lot james is a bus for Mail (big 'M'). Mail is defined by the Mailet API. ATM this definition only really allows JavaMail mail but this already excludes news. i would the Mailet 3.0 API to support a much wider range of messages (but not as wide as general service buses such as Camel. i see mail about being about MIME-typed documents with meta-data. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
