> I don't see the advantage of creating a new container just to get the
> language support for matchers, which seems to be part of what you are
> suggesting, if I understand you correctly.
I was trying to accomodate Noel's idea, I'm not 100% sure why he thinks we
need a SIEVE processor, but I
> While on the subject of direction, what do we want to do before cutting
the
> next major release?
- Do we want to take the current code as-is?
- Do we want to take the current code + latest Avalon,
which means pulling in Component->Service changes?
I prefer +Avalon, but as I'm not i
>By the way, I would consider starting this by forking LinearProcessor,
Oh what a good idea!
Yes +1 good stuff.
***
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not
+1
Also I'd be happy to direct mailet.org at it as I haven't got hosting ATM.
I'd even donate it to the project if we could afford to stump up for
renewals.
d.
***
The information in this e-mail is confidential and fo
> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]
> Sent: 18 November 2003 04:15
> To: James Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Future direction for James
>
>
> Jason Webb wrote:
> >>Personal filtering should be personally configurable. How
> >
> A language like Sieve, which is now an RFC, has its own notion of
matching,
> flow, and operation. As Steve pointed out, we could wrap all of that in
a
> Mailet (using the All matcher), but that seems kind of odd.
I get that but still think that implementing escapes to other languages
might
I can't remember the outcome of a recent conversation about what happens
to V3
Will the current head become a branch?
Will the branch_2_1_fcs become the head?
I would assume that next release will be 2.3 and include the latest
Avalon as well.
I hope to complete the user attribute work in the next
Noel J. Bergman wrote:
While on the subject of direction, what do we want to do before cutting the
next major release?
- Do we want to take the current code as-is?
- Do we want to take the current code + latest Avalon,
which means pulling in Component->Service changes?
+1 (please)
Steve.
> > I believe that adding Jelly support to the current Mailet
> > container is a better route than creating a new container.
>
> Why? The current container knows, or will know when some
> code is moved out
> of JamesSpoolManager, how to initialize its matchers and
> mailets from its
> own XML con
Danny Angus wrote:
I get that but still think that implementing escapes to other languages
might look better via a mailet.
I find these languages mainly useful because (in addition to being
easier to edit than XML IMO), it provides flow control that our
LinearProcessor does not, e.g., local varia
Danny Angus wrote:
+1
Also I'd be happy to direct mailet.org at it as I haven't got hosting ATM.
I'd even donate it to the project if we could afford to stump up for
renewals.
Danny,
If you need hosting, we've got an ASP-style content management system
that I could setup up to handle mailet.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why not wait for IMAP support while we're at it.
Stephen McConnell wrote:
|
|
| Noel J. Bergman wrote:
|
|> While on the subject of direction, what do we want to do before
|> cutting the
|> next major release?
|>
|> - Do we want to take the current c
> Why not wait for IMAP support while we're at it.
Because it would take too long. From what Jason just said about it taking a
few months before he has a chance to work on user attributes, I would not
want to wait for those, either, unless someone else has time to do them.
Most, if not all, of t
I'm a newbie both in Java and James, so be kind...
I'm making some modifications to James in order to build a prototype. I have
configured it to use a dbfile mailstore. I'm sending mime messages containing
audio/x-wav content, encoded base64. I do not use multipart.
The modification I need to ma
> I can't remember the outcome of a recent conversation about what
> happens to V3
> Will the current head become a branch?
> Will the branch_2_1_fcs become the head?
As I understand the concept, the desired changes from MAIN will be merged
into branch_2_1_fcs. Then MAIN will be pushed off as a
> > - Do we want to do additional refactoring of james-config.xml?
> Dunno, mabey as long as it represents an functional improvement
> not just a facelift.
More cosmetic. You can see what we did in v2.2 builds rather than adding
yet more sections to the file. I was thinking that we could factor
16 matches
Mail list logo
