Daniel Sadolevsky wrote:
> Is I understand from the mailing list archives, the people working on
> the framework are the same people that work on James, so if you don't care,
> then nobody does :-(
The *people* working on the framework are the same people that work on
James, implying more than just me. I'm sure Pier and some of the other
Java Apache members would care.
> Wrong, their implementation is well-defined also. There are so many RFCs
> that do define them in details ...
I'm using implementations in a different meaning. As I mentioned in my
example, MAIL FROM, RCPT TO, VRFY, could be accessing different user
lists depending on the sysadmin's preferences... maybe the
authentication is LDAP, Notes, an RDBMS, who knows? Yes, the response
codes would the similar.
> But you would never configure RCPT to look in 1) and in the same time
> configure VRFY to look in 3), right? IMHO more command-independent
> approach to configuration would work better
Alright, this is something maybe we should abstract... a user list...
and then provide multiple implementations like LDAP, maybe others to
start. That might be something to abstract and put as a configuration
setting which all the commands would reference.
> > What if you wanted to add your own
> > customized SMTP commands between the James server installed as the
> > gateway, and then multiple James mailbox servers? Granted
> > SMTP has been
> > around for forever, but I think we wanted to keep it flexible so that
> > you COULD take SMTP in new directions if you wanted it.
> > Otherwise with
> > the vertical design, the whole architecture gets cemented and
> > it becomes
> > extremely difficult to implement new approaches.
> >
> Not if we do it right :-)
Well, the proof would be in the pudding, as they say, but until I see
very convincing pudding, I would prefer to stick with the current
approach. We've purposefully pushed towards as much flexibility as
possible, and unless there are some beneficial, non-restrictive designs
to put back in place... If you can think of something, that'd be great.
> It's called "TURN", but there is no need in it - its initial purpose
> (connection
> reuse) became meaningless with time as TCP connections became cheaper, and
> some
> people even say it has security implications.
Well, I actually think the TURN command would be useful for your SEND
command example. TCP/IP connections are cheap, but they do cost some...
especially if you care about chat... time is crucial. So, person A
speaking to person B would ideally send all their chat messages over a
single TCP/IP connection. Without support for for the TURN command,
person B would then have to open another series of TCP/IP connections to
person A to send responses. So for a chat conversation, without TURN
support I would see you using 2 connections continuously, while with the
TURN command, you'd have 1 connection. Halve the number of connections,
you can [almost] double the scalability of the server (since the "mail"
servers are doing little more than streaming data back and forth].
> If I find anything that supports SEND when sending and notifies about IMAP
> EXISTS,
> I will probably use it. And, it's for some small (in distibution size)
> client app,
> so it should be in C++ or the like.
The ones I know of includes Jabber (http://www.jabber.org/ ?), Everbuddy
(http://www.everybuddy.com/), and probably some others. I'm really
looking to have a company or organization manageable chat server that
could interface with the external big chat systems, but that's outside
my interest in James. If you are at liberty, I'd like to hear more
about how users would use your system (platforms, apps, integration
plans, etc...). Probably best for offline though.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
