Actually, accessing the Imail sockets via a 3rd party com object, and and
API access to the Imail core are two COMPLETELY different things. I can't
speak for everyone here, but I want API access so I can directly manipulate
any and every part of Imail. I believe that using a 3rd party COM can be
very useful, but it wouldn't compare to the speed and flexibility of a
direct API. Not by any stretch of the imagination. I believe that those
who compare a socket component to an API have a great misconception of what
an API is.
IMHO,
Chris
----------------------------------------------
Original Message
From: "Len Conrad"<[EMAIL PROTECTED]>
Subject: RE: [IMail Forum] ServerObjects ASP Mail
Date: Wed, 08 Sep 1999 18:44:54 +0200
>
>>Excuse me, but am I missing something?
>apparently. The demand here was for the Imail product to offer a
scriptable
>API itself, without the need for "solutions out there" which most of us
>know about.
>
>>The whole point (at least I thought it was) of an API to IMail is to gain
>>programmatic access to the IMail-specific features such as username and
>>password configuration, forwarding, filtering, etc. These features are
>>not part of POP3/IMAP/SMTP but are specific to each server or client
software.
>
>access to those proprietairy functions, too, yes. If Ipswitch was going
to
>offer an API for the proprietary/admin bits, why not for the production
>functions like smtp, POP3, whatever?
>
>>
>>The need for an API is for these functions. Everything else can be
>>"gotten at" through all kinds of existing methods (sorry for the pun).
>
>why pay more to someone else? I'd rather pay more, or nothing, to
Ipswitch
>for all these functions to be accessible by API, COM objects being a
natural.
>
>Len
>
>==========
Chris Terrebonne
[EMAIL PROTECTED]
http://www.myownemail.com
_____________________________________________
Free email with personality! Over 200 domains!
http://www.MyOwnEmail.com
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.