> > - 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
> 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
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
> 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
-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
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
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
> > 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
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 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
> 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
> -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
> >
+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
>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
> 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
> 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
16 matches
Mail list logo
