On 5/24/07, Eric Rostetter <[EMAIL PROTECTED]> wrote:
Quoting Marc Perkel <[EMAIL PROTECTED]>:
> Yes - with the ability to ise IMAP as a connection channel you could do
> anything that Microsoft Exchange does and more. The idea is that you
> can establish a connection between any server app and any client app.
Yes, this is correct, and what some people are asking for.
> Generally you would want it to be somewhat email related but it's wide
> open and doesn't have to be.
But managing this becomes more complex as you add more functions and
the functions diverge from email in nature.
> And what's wrong with unlimited
> functionality?
Nothing. It is how you get there that matters.
The problem of putting all your eggs in one basket is:
1) It doesn't scale well.
2) If you lose the basket, you loose all your eggs.
3) The basket becomes more complex to program, debug, audit, manage, document,
etc.
4) The basket _may_ become slower, consume greater resources, etc.
> Keep in mind that one of the reasons people buy Exchange is because
> Exchange does things that people want.
And one of the reasons so many of them complain about Exchange is because
it does most of them poorly, is hard to manage and maintain, and if it
breaks you lose access to everything, not just to one thing.
> A calendar is one of many
> examples. But to start with I'm thinking more in terms of controlling
> server side email settings.
For which various protocols already exist...
As already stated, unless this goes through some standards body, it
probably won't be widely adopted or used... So IMHO, the place to
start would be with trying to define a standard and get support for
it, rather than coding non-standards-based code that will only be
adopted by a few...
choose a minimum set of things to do and implement them correctly.
"divide and conquer" paradigm often works well.
--
DINH Viêt Hoà