On 2/1/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
yeh (but i'm trying to learn as little as possible about it). i
suspe
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
had a talk with some of the DAV folks last year. AIUI the right way to
do it would be to standardize a small amount of emai
On 1/31/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
>
> the resources that i think are of interest are emails, meta-data about
> emails, collections of emails and meta-data about collections of
> emails. these concepts already have natural correspondents in HTTP and
> WebDAV
>
U/F it looks l
smooth operation means being able to feed information about changes
back to the client which needs a little more thought
With HTTP 1.1 persistent connections this is possible and still allows
some of that pool magic. It can be a configurational pain (timeouts on
routers and stuff) but possi
the resources that i think are of interest are emails, meta-data about
emails, collections of emails and meta-data about collections of
emails. these concepts already have natural correspondents in HTTP and
WebDAV
U/F it looks like although WEBDAV would be natural, just getting a list
O'stuff
On 1/28/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
RESTfulness is a red herring.
not so much a red herring as an orthogonal kipper ;-)
yes, i admit i used a lie of juxaposition
It is not lack of "RESTfulness" that
makes IMAP suck. It is that it is a complex and inspecific protocol
with
tas
Betreff: RESTful email [WAS Re: MailboxManager API and session
orientation was: Jsieve Configuration]
On 1/25/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]>
wrote:
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wr
On 1/27/07, Jürgen Hoffmann <[EMAIL PROTECTED]> wrote:
Hi Robert,
and who would want that sort of feature, when he can have imap?
IMAP is a great example of a very bad protocol totally unsuitable for
the internet
RSS/Atom is
more for webapps, which want to inform a user of site updates.
th
t; Von: robert burrell donkin [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 27. Januar 2007 12:37
> An: James Developers List; Serge Knystautas
> Betreff: RESTful email [WAS Re: MailboxManager API and session
> orientation was: Jsieve Configuration]
>
> On 1/25/07, Serge Knystautas &
On 1/25/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
>
>
>
> > I would suggest looking briefly at the raw IMAP protocol. It makes
> > the protocol nasty, but every command g
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
> I would suggest looking briefly at the raw IMAP protocol. It makes
> the protocol nasty, but every command gets a unique token so that
> requests and responses are asynchrono
On 1/24/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> robert burrell donkin wrote:
(i've had a chance to take a look at the rfc)
> What about multiple IMAP clients accessing the same imap folder? Are
> message identifiers diffe
On 1/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> Initially I thought this thread was about 3, while your diagrams seems
>> to me about 1: this is why I'm confused.
>
> the diagram concerns the interface between the handler and processor
> layers (as defined a
Serge Knystautas wrote:
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> commands that rely on or change message ID must be serialized and
> executed in the order that the client has sent them.
Ok now I understand the issue. I started from the, now I understand
wrong, assumption tha
On 1/23/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a unique token so that
requests and responses are asynchronous. I would presume this is why
someone like Andy will question th
On 1/23/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in your inbox. You move ema
robert burrell donkin wrote:
commands that rely on or change message ID must be serialized and
executed in the order that the client has sent them.
Ok now I understand the issue. I started from the, now I understand
wrong, assumption that IMAP commands have to be executed synchronously
and se
On 1/22/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> one of the tricky points about IMAP is that reasonable performance
> requires that commands be executed in parallel but there are complex
> rules that must be applied to the scheduling. to support concurrent
> a
robert burrell donkin wrote:
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> About the command pattern applied to our services we are already
working
>> on a common infrastructure to reuse part of our network layer between
>> services and prepare for
robert burrell donkin wrote:
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
the diagram concerns the interface between the handler and processor
layers (as defined above)
i think that i now understand the reason for this confusio
robert burrell donkin wrote:
What you propose have IMAP all the way: I don't understand how you can
say it is more generic and less coupled. Am I missing the whole point?
perhaps one of them at least :-)
I was sure :-)
IMAP is a difficult protocol. making a implementation which performs
ok
robert burrell donkin wrote:
one of the tricky points about IMAP is that reasonable performance
requires that commands be executed in parallel but there are complex
rules that must be applied to the scheduling. to support concurrent
access to the same mailbox by multiple clients requires understa
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
"hooks" in POP3 or
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> About the command pattern applied to our services we are already working
>> on a common infrastructure to reuse part of our network layer between
>> services and prepare for asynchronous handling: you can
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I try to restart from scratch and summarize.
I think our main layers are
1) Protocol handling
2) Message processing
3) Message storage
Most of the Joachim work is about the message storage.
IMHO no
but at moment the implementation log
On 1/18/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
> I think our goal is to share as most handler-api code as possible. So
> why we should not try to create an handler-api which fit all needs
> (POP3,IMAP,SMTP) ?
> In SMTP it is called fa
On 1/18/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
Stefano Bagnara wrote:
> Danny Angus wrote:
> > On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> PS: I don't understand why this thread seems a me against robert or
> danny. I'm simply trying to understand robert ideas, and to ask hi
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I think that a command pattern having an ImapCommand as the command
>> cannot be the api to the backend (the MailboxManager). The
>> MailboxManager shoudl be able to provide results for Imap, for POP3, and
Stefano Bagnara wrote:
> Danny Angus wrote:
> > On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> PS: I don't understand why this thread seems a me against robert or
> danny. I'm simply trying to understand robert ideas, and to ask him
> explanations. I did this with Joachim when he prov
On 1/18/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
IMHO "handlerapi" should not be smtp specific: we use handler for every
protocol. Maybe someone doesn't share this view, but I thought this was
the main intent in calling "handler api". At least the pattern (if not
the code) can be (and IMHO
Danny Angus wrote:
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Let me better approach this discussion: what is your knowledge of the
whole james code (in particular the smtpserver/handler), how it changed
in 2.3.0, how it changed in trunk, then in the 2 experimental branches
and now i
On 1/18/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
"hooks" in POP3
Danny Angus schrieb:
> On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> robert burrell donkin wrote:
>> >> I think this is a step back from the current design or it simply
>> regards
>> >> something we already trying to solve differently with the handlerapi.
>> >
>> > the current API desig
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> I think this is a step back from the current design or it simply regards
>> something we already trying to solve differently with the handlerapi.
>
> the current API design is flawed: this is just one way to fi
On 1/17/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
from what i can tell from looking at the newer code, you seem to be
moving towards a messaging API but the interfaces suffer from the
usual faults (too complex, probably unmaintainable going forward).
+1.
ATM you have an inefficien
robert burrell donkin wrote:
I think this is a step back from the current design or it simply regards
something we already trying to solve differently with the handlerapi.
the current API design is flawed: this is just one way to fix it.
Let me better approach this discussion: what is your kn
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> i've taken the liberty to create:
> http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles to
> house speculations such as this.
>
> i've added something very basic to
>
http://svn.apache.org/repos
robert burrell donkin wrote:
i've taken the liberty to create:
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles to
house speculations such as this.
i've added something very basic to
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/imap/messaging-api/.
it
> -Original Message-
> From: robert burrell donkin [mailto:[EMAIL PROTECTED]
> Sent: 15 January 2007 20:30
> To: James Developers List
> Subject: Re: MailboxManager API and session orientation was: Jsieve
> Configuration
>
>
> On 1/13/07, Norman Maure
On 1/13/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Steve Brewin schrieb:
> robert burrell donkin wrote:
>
>
>> if there's interest, maybe i'll pull together some UML
>>
>
> Get on with it then :)
>
> Cheers
>
> -- Steve
>
>
+1
i've taken the liberty to create:
http://svn.apache.org/repos/as
Steve Brewin schrieb:
> robert burrell donkin wrote:
>
>
>> if there's interest, maybe i'll pull together some UML
>>
>
> Get on with it then :)
>
> Cheers
>
> -- Steve
>
>
+1
Norman
-
To unsubscribe, e-mail: [EMAIL
robert burrell donkin wrote:
>
> if there's interest, maybe i'll pull together some UML
Get on with it then :)
Cheers
-- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 1/13/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> manage the state more clearly. allow the backend access to more
> information about the conversational state. the parsing layer should
> manage the conversational state but this should be done through an
> inter
robert burrell donkin wrote:
manage the state more clearly. allow the backend access to more
information about the conversational state. the parsing layer should
manage the conversational state but this should be done through an
interface. the implementation should be provided by the backend
allo
On 1/13/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Samstag, den 13.01.2007, 10:53 + schrieb robert burrell donkin:
> > > this is a good example of why i claim that state needs to considered
> > > more carefully. hopefully it may also illustrate why i claim that
> > > session is harmfu
Am Samstag, den 13.01.2007, 10:53 + schrieb robert burrell donkin:
> > > this is a good example of why i claim that state needs to considered
> > > more carefully. hopefully it may also illustrate why i claim that
> > > session is harmful.
> >
> > That's not fair. :-( It's just an example for
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Donnerstag, den 11.01.2007, 20:14 + schrieb robert burrell
donkin:
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
> > donkin:
> >
> > > > > > Think of a mb
Am Donnerstag, den 11.01.2007, 20:14 + schrieb robert burrell
donkin:
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
> > donkin:
> >
> > > > > > Think of a mbox and pop3. The backend opens the file and indexes it.
>
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
> > In fact sessions bring a bit inconvenience for the developer. But in the
> > past stateless MailRepositories made problems. They were solved by
> > putting it in
robert burrell donkin wrote:
>
>
> On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert
> burrell donkin:
>
>
>
> > > > Think of a mbox and pop3. The backend opens the file
> and indexes it.
> > >
> > > that is not conversational state
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
donkin:
> > > > Think of a mbox and pop3. The backend opens the file and indexes it.
> > >
> > > that is not conversational state but an optimization
> >
> > Right, but withou
Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
donkin:
> > > > Think of a mbox and pop3. The backend opens the file and indexes it.
> > >
> > > that is not conversational state but an optimization
> >
> > Right, but without a session there is no possibility for that
> > optimiza
On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
> > Think of a mbox and pop3. The backend opens the file and indexes it.
>
> that is not conversational state but an optimization
Right, but without a session there
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
> > > > From the other side developers maybe just don't need a full featured
> > > > ImapSession for their needs and want to use an easier interface.
> > > >
> > > > That was the intention for providing different "flavors" of
On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Dienstag, den 09.01.2007, 21:59 + schrieb robert burrell donkin:
> > From the other side developers maybe just don't need a full featured
> > ImapSession for their needs and want to use an easier interface.
> >
> > That was the in
On 1/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>> From the other side developers maybe just don't need a full featured
>> ImapSession for their needs and want to use an easier interface.
>>
>> That was the intention for providing different "flavors" of ses
On 1/10/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Joachim Draeger wrote:
> Am Mittwoch, den 10.01.2007, 17:39 + schrieb robert burrell donkin:
>> this [the STATUS command] is basically an atomic, stateless operation. there
should be no
>> need to open a heavyweight session to execute it
Joachim Draeger wrote:
Am Mittwoch, den 10.01.2007, 17:39 + schrieb robert burrell donkin:
this [the STATUS command] is basically an atomic, stateless operation. there
should be no
need to open a heavyweight session to execute it.
I don't understand how you can define the "STATUS" command
On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 17:39 + schrieb robert burrell donkin:
> when using IMAP, one way to do this is by issuing a SEARCH command
> specifying mailbox and the criteria. AFIAK this command does not
> depend on which mailbox has bee
On 1/10/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, den 10.01.2007, 17:53 + schrieb robert burrell donkin:
> > On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > clients are typically interested only in
On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 17:53 + schrieb robert burrell donkin:
> On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> clients are typically interested only in a subset of the headers
Right. For current implementation:
I alr
Am Mittwoch, den 10.01.2007, 17:53 + schrieb robert burrell donkin:
> On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> > For instance fetching a small subset of the headers of many messages has
> > to be done in an optimal way. (e.g. in one SQL query)
>
> not just a single query but a
Am Mittwoch, den 10.01.2007, 17:39 + schrieb robert burrell donkin:
> when using IMAP, one way to do this is by issuing a SEARCH command
> specifying mailbox and the criteria. AFIAK this command does not
> depend on which mailbox has been selected or the current client state,
> just the data.
On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 00:04 +0100 schrieb Stefano Bagnara:
> >> > there are various methods to get various
> >> > flavours of session.
> >>
> >> Currently there are three.
> >> The problem is that IMAP has many requirements to a bac
On 1/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> IMAP as a protocol has some commands which are naturally stateful and
> some which are more naturally stateless. superficially at least, it
> seems more natural to me to think about a stateful session layeri
Am Mittwoch, den 10.01.2007, 00:04 +0100 schrieb Stefano Bagnara:
> >> > there are various methods to get various
> >> > flavours of session.
> >>
> >> Currently there are three.
> >> The problem is that IMAP has many requirements to a backend. Many
> >> backends successfully used for POP3 will
Am Dienstag, den 09.01.2007, 21:59 + schrieb robert burrell donkin:
> AFAIK SIEVE scripts conceptually operate once mail has been delivered
> to a user. how do you see the configuration working?
The LocalDeliver Mailet is the point in the chain where the Mail gets
just delivered. In fact it i
robert burrell donkin wrote:
AFAIK SIEVE scripts conceptually operate once mail has been delivered
to a user. how do you see the configuration working?
Can you elaborate?
What does it happens if I'm checking my pop3 inbox after a message has
been delivered there but before the sieve script has
On 1/9/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Montag, den 08.01.2007, 22:22 + schrieb robert burrell donkin:
> > So I'm going to write a MailboxManager LocalDelivery and
> > LocalSieveDelivery.
>
> could you explain just a little more about these?
There is nothing magic about it.
Am Montag, den 08.01.2007, 22:22 + schrieb robert burrell donkin:
> > So I'm going to write a MailboxManager LocalDelivery and
> > LocalSieveDelivery.
>
> could you explain just a little more about these?
There is nothing magic about it. :-) Current LocalDelivery accesses
MailRepositories.
I
(with danny's permission, moving this back on list after accidental
personal communication)
On 1/8/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 1/8/07, Danny Angus <[EMAIL PROTECTED]> wrote:
> On 1/7/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
>
> > advanced email servers end
On 1/8/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Freitag, den 05.01.2007, 19:56 +0100 schrieb Joachim Draeger:
> Am Freitag, den 05.01.2007, 09:19 + schrieb Danny Angus:
>
> > > The best way would be a native, logical, hierarchical mailbox access
> > > through the Mailet API.
> >
> >
On 1/8/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
What you are probably interested in is an example for the use case
"MailboxManager usage inside a Mailet". This can also be done in trunk.
Yes correct. :-)
-
To unsubscrib
Am Freitag, den 05.01.2007, 19:56 +0100 schrieb Joachim Draeger:
> Am Freitag, den 05.01.2007, 09:19 + schrieb Danny Angus:
>
> > > The best way would be a native, logical, hierarchical mailbox access
> > > through the Mailet API.
> >
> > If you would like to expand on this idea I'd be intere
Stefano Bagnara wrote:
> Steve Brewin wrote:
>
> I'm sorry I probably not explained it well.
You explained it fine, I just didn't have my brain in gear!
Cheers
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
On 1/6/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 1/6/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
> On 1/6/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> > sorting isn't good enough for me either: emails need to be tagged with
> > meta-data on the server. meta-data can then used to
On 1/6/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/6/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> sorting isn't good enough for me either: emails need to be tagged with
> meta-data on the server. meta-data can then used to present a folder
> based view to a client or for any ot
On 1/6/07, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On 1/6/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> sorting isn't good enough for me either: emails need to be tagged with
> meta-data on the server. meta-data can then used to present a folder
> based view to a client or for any ot
On 1/6/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
sorting isn't good enough for me either: emails need to be tagged with
meta-data on the server. meta-data can then used to present a folder
based view to a client or for any other purposes. i think that a rules
engine plus a domain speci
On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
BTW: Integrating IMAP, jSieve and Mailboxmanager, is one important goal
for me. I personally find it very comfortable to get the mail sorted on
server side and access it from different computers via IMAP.
interesting :-)
this sounds simi
Steve Brewin wrote:
Stefano Bagnara wrote:
Maybe this is not related, but I changed this from 2.2.0 to
2.3.0. After
the Phoenix update we could now rely on the classloader
phoenix provide
to James, that already lookup SAR-INF/classes and SAR-INF/lib. So we
don't have anymore a custom classloader
Danny Angus wrote:
> On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
>
>
> > The best way would be a native, logical, hierarchical mailbox access
> > through the Mailet API.
>
> If you would like to expand on this idea I'd be interested in seeing
> what it looks like when applied to sandbox/
Stefano Bagnara wrote:
>
> Steve Brewin wrote:
> > robert burrell donkin wrote:
> >> AFAIK you need to alter the master configuration files. be
> cool to be
> >> able to have a new component packaged in a jar with some
> xml whatknot
> >> and have james pick it up.
> >>
> > In James? The mailet cla
Am Freitag, den 05.01.2007, 21:10 +0100 schrieb Stefano Bagnara:
> > I guess jSieve just needs a possibility to access different
> > folders/mailboxes that can be accessed by the user through IMAP.
> > Today this would mean access to the MailboxManager. (the IMAP capable
> > backend, not the IMAP
Steve Brewin wrote:
robert burrell donkin wrote:
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
In James? The mailet classloader will look in SAR-INF/classes and
SAR-INF/lib
robert burrell donkin wrote:
is there any way to drop in a new component ATM?
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
- robert
I think that Phoenix does not have this
Joachim Draeger wrote:
I guess jSieve just needs a possibility to access different
folders/mailboxes that can be accessed by the user through IMAP.
Today this would mean access to the MailboxManager. (the IMAP capable
backend, not the IMAP server itself)
Does it need access to a repository cont
Am Freitag, den 05.01.2007, 09:19 + schrieb Danny Angus:
> > The best way would be a native, logical, hierarchical mailbox access
> > through the Mailet API.
>
> If you would like to expand on this idea I'd be interested in seeing
> what it looks like when applied to sandbox/mailet-refactorin
Am Freitag, den 05.01.2007, 11:24 + schrieb Danny Angus:
> > >> The best way would be a native, logical, hierarchical mailbox access
> > >> through the Mailet API.
> > >
> > > If you would like to expand on this idea I'd be interested in seeing
> > > what it looks like when applied to sandbox/
On 1/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
Ha! Yes, We've discussed this before in relation to deployment of
m
On 1/5/07, Norman Maurer <[EMAIL PROTECTED]> wrote:
Danny Angus schrieb:
> On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
>
>
>> The best way would be a native, logical, hierarchical mailbox access
>> through the Mailet API.
>
> If you would like to expand on this idea I'd be interested in
Danny Angus schrieb:
> On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
>
>
>> The best way would be a native, logical, hierarchical mailbox access
>> through the Mailet API.
>
> If you would like to expand on this idea I'd be interested in seeing
> what it looks like when applied to sandbox/m
On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to sandbox/mailet-refactorings/. If
you want
Am Donnerstag, den 04.01.2007, 21:24 + schrieb Steve Brewin:
> > > Full integration is a pending James activity awaiting the
> > completion of our
> > > IMAP implementation which will bring with it the required
> > infrastructure to
> > > make jSieve truly useful.
> The Sieve spec. is predic
Steve Brewin schrieb:
> robert burrell donkin wrote:
>
>> On 1/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
>>
>>> Lokesh Babu wrote:
>>>
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with ja
robert burrell donkin wrote:
>
> On 1/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
> > Lokesh Babu wrote:
> > >
> > > Hi,
> > >
> > > i have to integrate Jsieve with james mailserver,can anyone
> > > please provide
> > > the process of jsieve integration with james
> mailserver/hmailserver.
> >
>
robert burrell donkin wrote:
>
>
> On 1/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
> > Lokesh Babu wrote:
> > >
> > > Hi,
> > >
> > > i have to integrate Jsieve with james mailserver,can anyone
> > > please provide
> > > the process of jsieve integration with james
> mailserver/hmailserver.
> >
On 1/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
Lokesh Babu wrote:
>
> Hi,
>
> i have to integrate Jsieve with james mailserver,can anyone
> please provide
> the process of jsieve integration with james mailserver/hmailserver.
Take a look at package org.apache.jsieve.samples.james and be sure
On 1/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
Lokesh Babu wrote:
>
> Hi,
>
> i have to integrate Jsieve with james mailserver,can anyone
> please provide
> the process of jsieve integration with james mailserver/hmailserver.
Take a look at package org.apache.jsieve.samples.james and be sure
1 - 100 of 102 matches
Mail list logo
