On Nov 24, 2007 9:04 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Nov 21, 2007 4:30 PM, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
> > i've committed the change from arrays to iterators. the next step is
> > to switch torque to load the heavy data (body and headers) upon
> > it
Hi,
I've written at least 3 closed source "user" modules in my life.
every second webapp seems to need it, and servers like James and
Vysper need it, too.
There is a generic implementation at OpenSymphony.OSUser, but it seems stale.
A user module typically needs:
+ Account data (name, nicks, ide
On Nov 24, 2007 11:58 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 9:01 PM, Bernd Fondermann
>
> <[EMAIL PROTECTED]> wrote:
> > On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
> > <[EMAIL PROTECTED]> wrote:
> > > On Nov 24, 2007 4:53 PM, Bernd Fondermann
> > >
> > > <[EMAIL
On Nov 24, 2007 11:08 PM, Danny Angus <[EMAIL PROTECTED]> wrote:
> ...
> P.S. I like the "Store" entitity because it would allow the mailet API
> to expose multiple different sets of respositories, but they're
> (stores & repository access) used inconsistently in James at the
> moment. And I think
...
P.S. I like the "Store" entitity because it would allow the mailet API
to expose multiple different sets of respositories, but they're
(stores & repository access) used inconsistently in James at the
moment. And I think we need to be more consistent with some of our
abstrations & implementation
On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> 1 the granularity of the components is debatable. including user
> repositories, stores and virtual user tables together seemed
> reasonable to me but perhaps there are better arrangements.
This is another area I've been thinking ab
On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> i'm happy to rename all of them so how about administration for each
> interface and administrator for each implementation?
+1 Bernd's comment makes sense.
d.
-
T
On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> after modularisation, the user-api module should contain only basic
> interfaces with no coupling to other parts of JAMES or avalon.
Cool. I think this needs to go into the mailet API, because mailet is
pretty helpless without some
On Nov 24, 2007 9:01 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
> > On Nov 24, 2007 4:53 PM, Bernd Fondermann
> >
> > <[EMAIL PROTECTED]> wrote:
> > > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
> > >
> > > <[EMAI
On Nov 24, 2007 9:02 PM, Danny Angus <[EMAIL PROTECTED]> wrote:
> I was going to nick some of the users stuff for mailet at some point,
> because the API needs users or it can never be complete. Therfore if
> you could keep this in the back of your mind and don't make the API
> too Jamesey it might
i've been experimenting with modularisation of the code related to
users. i'd like to split into separate api, library and implementation
components.
the list is a little long to fit comfortably in an email so i've
posted it to the wiki (1) . below are some comments and questions
1 the granularit
On Nov 24, 2007 8:51 PM, Steve Brewin <[EMAIL PROTECTED]> wrote:
> Hi All
>
> As IOC is often mentioned here and pico in particular, some may be
> interested in http://wiki.apache.org/incubator/ComposerProposal.
Yeah, we are all exited about it since Noel mentioned it on Oct 8th. :-)
Bernd
---
I was going to nick some of the users stuff for mailet at some point,
because the API needs users or it can never be complete. Therfore if
you could keep this in the back of your mind and don't make the API
too Jamesey it might make it easier to derive the mailet users stuff
from your work when the
On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 4:53 PM, Bernd Fondermann
>
> <[EMAIL PROTECTED]> wrote:
> > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
> >
> > <[EMAIL PROTECTED]> wrote:
> > > http://svn.apache.org/repos/asf/james/server/trunk/core-li
> why not call the implementation VirtualUserTableManager?
Aha! Using the power of sematics you have triumphed! :-)
Yes, the purpose is "Management" the realisation requires the
existence of a "Manager"
d.
-
To unsubscribe, e-ma
On Nov 24, 2007 7:37 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 8:25 PM, Robert Burrell Donkin
> > if all management exceptions inherit from a common super class then
> > this couples packages together. this this is useful then that's fine.
> > if there isn't any good reas
Hi All
As IOC is often mentioned here and pico in particular, some may be
interested in http://wiki.apache.org/incubator/ComposerProposal.
I'm unsure of the current status or roadmap, but it would be good to see IOC
coming home to Apache again.
Cheers
Steve
---
On Nov 24, 2007 8:25 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 5:34 PM, Bernd Fondermann
> <[EMAIL PROTECTED]> wrote:
> > On Nov 24, 2007 12:59 PM, Robert Burrell Donkin
> > <[EMAIL PROTECTED]> wrote:
> > > i'm trying to factor out a user-library module but i'm having p
On Nov 24, 2007 4:53 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
>
> <[EMAIL PROTECTED]> wrote:
> > http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/services/VirtualUserTableManagement.java
> > and
>
On Nov 24, 2007 5:34 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 12:59 PM, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
> > i'm trying to factor out a user-library module but i'm having problems
> > since the management interfaces throw exceptions which subclass
> > Mana
Author: rdonkin
Date: Sat Nov 24 11:18:22 2007
New Revision: 597905
URL: http://svn.apache.org/viewvc?rev=597905&view=rev
Log:
Illustration of packaging issues.
Added:
james/server/sandbox/design-doodles/modules/management-packaging.dia
(with props)
james/server/sandbox/design-doodles/
On Nov 24, 2007 12:59 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> i'm trying to factor out a user-library module but i'm having problems
> since the management interfaces throw exceptions which subclass
> ManagementException. i don't understand why this coupling is necessary
a managemen
On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/services/VirtualUserTableManagement.java
> and
> http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/
Hi,
> Maybe It whould be better to call the Implementation
> org.apache.james.management.VirtualUserTableManagementImpl
Just my 2c here ... but ...
I'm not a big fan of naming implementations with "impl". Why? Well
the purpose of an interface is to describe an abstract class if thing
or a general
Hi robert,
I maybe choose stupid naming when I was workin on this...
org.apache.james.services.VirtualUserTableManagement <- Interface
org.apache.james.management.VirtualUserTableManagement <-
Implementation
Maybe It whould be better to call the Implementation
org.apache.james.management.Virtua
http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/services/VirtualUserTableManagement.java
and
http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/management/VirtualUserTableManagement.java.
i
anyone know why?
i'm trying to factor out a user-library module but i'm having problems
since the management interfaces throw exceptions which subclass
ManagementException. i don't understand why this coupling is necessary
so i'm tempted to eliminate this class and push the implementations
down into each subclass.
On Nov 22, 2007 8:53 PM, Tim Stephenson <[EMAIL PROTECTED]> wrote:
> Thanks for so many quick replies. I will take a look at JSieve though
> since I know Rhino I must confess that sounds quite attractive.
>
> From your comments I gathered a next generation API might on the cards
> and also that a c
i plan to split the users code out from core-library into an API,
library and implementation modules. please jump in soon if this isn't
convenient right now.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional com
On Nov 16, 2007 5:25 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Nov 7, 2007 1:53 PM, Danny Angus <[EMAIL PROTECTED]> wrote:
> > On 06/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> >
> > > Zsombor suggests object storage.
> >
> > ...
> >
> > > (not sure i have a strong p
On Nov 21, 2007 4:30 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> i've committed the change from arrays to iterators. the next step is
> to switch torque to load the heavy data (body and headers) upon
> iteration.
>
> loading the heavy data may fail and this failure will occur not during
31 matches
Mail list logo
