SourceForge.net | 15 Mar 19:12 2005
Picon
Picon

[ libetpan-Feature Requests-1163923 ] C++ friendly interface

Feature Requests item #1163923, was opened at 2005-03-15 18:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429699&aid=1163923&group_id=41064

Category: Interface
Group: libEtPan!
Status: Open
Priority: 5
Submitted By: David Gal (davidgal)
Assigned to: Nobody/Anonymous (nobody)
Summary: C++ friendly interface

Initial Comment:
Interface functions that take "char*" parameters should 
be changed to take "const char*" parameters where 
appropriate. This would certainly making linking to C++ 
applications easier.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429699&aid=1163923&group_id=41064

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
(Continue reading)

SourceForge.net | 16 Mar 00:44 2005
Picon
Picon

[ libetpan-Feature Requests-1163923 ] C++ friendly interface

Feature Requests item #1163923, was opened at 2005-03-15 18:12
Message generated for change (Comment added) made by hoa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429699&aid=1163923&group_id=41064

Category: Interface
Group: libEtPan!
Status: Open
Priority: 5
Submitted By: David Gal (davidgal)
Assigned to: Nobody/Anonymous (nobody)
Summary: C++ friendly interface

Initial Comment:
Interface functions that take "char*" parameters should 
be changed to take "const char*" parameters where 
appropriate. This would certainly making linking to C++ 
applications easier.

----------------------------------------------------------------------

>Comment By: DINH V. Hoa (hoa)
Date: 2005-03-15 23:44

Message:
Logged In: YES 
user_id=201468

Could you give more details about functions that take char *
that will not be friendly ?
(Continue reading)

SourceForge.net | 16 Mar 10:39 2005
Picon
Picon

[ libetpan-Feature Requests-1163923 ] C++ friendly interface

Feature Requests item #1163923, was opened at 2005-03-15 10:12
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429699&aid=1163923&group_id=41064

Category: Interface
Group: libEtPan!
Status: Open
Priority: 5
Submitted By: David Gal (davidgal)
Assigned to: Nobody/Anonymous (nobody)
Summary: C++ friendly interface

Initial Comment:
Interface functions that take "char*" parameters should 
be changed to take "const char*" parameters where 
appropriate. This would certainly making linking to C++ 
applications easier.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-03-16 01:39

Message:
Logged In: NO 

I've only just started looking at the library so don't know it in 
any huge detail at the moment.

(Continue reading)

Luke Ehresman | 21 Mar 22:25 2005

multithreaded use

Hello,

I'm excited to find libetpan!  I have been using c-client, but
discovered its limitations in a multi-threaded environment.  I have
searched and searched for another good C imap library, but for some
reason never ran across this project until now.  It looks like exactly
what I need.

I have read through the documentation and there was one question I
still have that was left unanswered.  Is this library thread safe?  The
c-client library is not, and I started working on making it thread
safe, but it was going to be a massive project.

I am working on a multi-user webmail system (Aeromys --
www.aeromys.org).  Each user will have a unique connection to his or
her mail server.  There will only be one connection per user, but there
will be multiple users in different threads.  Will this library handle
this situation without problems?

Along the same lines, would it be possible for me to remove the
limitation of having only one thread working on a connection at a
time?  By this I mean, could I have a background thread caching mail
for the user while he/she is also browsing?  Both of these threads
would be working on the same connection.

Thanks for your time, I am seriously hoping this library will save me
from having to write my own.  It looks very promising.  Good work, and
thanks.

Luke
(Continue reading)

DINH Viet Hoa | 21 Mar 22:46 2005
Picon

Re: multithreaded use

Hello,

Luke Ehresman wrote :

> I'm excited to find libetpan!  I have been using c-client, but
> discovered its limitations in a multi-threaded environment.  I have
> searched and searched for another good C imap library, but for some
> reason never ran across this project until now.  It looks like exactly
> what I need.
> 
> I have read through the documentation and there was one question I
> still have that was left unanswered.  Is this library thread safe?  The
> c-client library is not, and I started working on making it thread
> safe, but it was going to be a massive project.

libetpan is not thread safe but it is reentrant.
That means that you can do calls from several thread if you do
manipulate different datastructure in those threads.

> I am working on a multi-user webmail system (Aeromys --
> www.aeromys.org).  Each user will have a unique connection to his or
> her mail server.  There will only be one connection per user, but there
> will be multiple users in different threads.  Will this library handle
> this situation without problems?

That kind of situation will be handled without problems.

> Along the same lines, would it be possible for me to remove the
> limitation of having only one thread working on a connection at a
> time?  By this I mean, could I have a background thread caching mail
(Continue reading)

Luke Ehresman | 21 Mar 22:59 2005

Re: multithreaded use

Awesome!  you guys just saved me several months worth of work to
produce something that wouldn't have been as advanced as what you
currently have.  Thanks!  I look forward to working with this library
and with your development team in the future.

Luke

On Mon, 21 Mar 2005 22:46:40 +0100
DINH Viet Hoa <dinh.viet.hoa@...> wrote:

> Hello,
> 
> Luke Ehresman wrote :
> 
> > I'm excited to find libetpan!  I have been using c-client, but
> > discovered its limitations in a multi-threaded environment.  I have
> > searched and searched for another good C imap library, but for some
> > reason never ran across this project until now.  It looks like exactly
> > what I need.
> > 
> > I have read through the documentation and there was one question I
> > still have that was left unanswered.  Is this library thread safe?  The
> > c-client library is not, and I started working on making it thread
> > safe, but it was going to be a massive project.
> 
> libetpan is not thread safe but it is reentrant.
> That means that you can do calls from several thread if you do
> manipulate different datastructure in those threads.
> 
> > I am working on a multi-user webmail system (Aeromys --
(Continue reading)

Luke Ehresman | 28 Mar 17:55 2005
Picon

folder listing

I have been reading through the libEtPan API and am a bit confused at the
interface provided.  I hope someone can clarify some of my questions.

1)  As a developer, how do I connect to a generic mail server.  I want to
be able to have users conigure POP3, IMAP, etc.  Is there a generic way to
connect to mail servers, or do I need to do it different for each one? 
Specifically, my confusion on this issue comes from the example which uses
imap_mailstorage_init() to connect to an IMAP server.  I have successfully
connected using this method, but I assume this would only connect to IMAP
servers.

2)  What is the use of sessions?  I would have thought that a session
would envelop a storage, but it seems that the storage data structure is
what I pass to all the functions in order to retrieve messages and
folders.  How are sessions used in libEtPan?

3)  How do I get a listing of folders on an IMAP server?  There are some
functions listed in the session driver, but they are all depricated, and I
have not found any reference to "lsub" in the etPan client, or in the
libEtPan documentation.

Thanks for your help.
Luke

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
(Continue reading)

DINH Viet Hoa | 28 Mar 18:36 2005
Picon

Re: folder listing

Luke Ehresman wrote :

> I have been reading through the libEtPan API and am a bit confused at the
> interface provided.  I hope someone can clarify some of my questions.
> 
> 1)  As a developer, how do I connect to a generic mail server.  I want to
> be able to have users conigure POP3, IMAP, etc.  Is there a generic way to
> connect to mail servers, or do I need to do it different for each one? 
> Specifically, my confusion on this issue comes from the example which uses
> imap_mailstorage_init() to connect to an IMAP server.  I have successfully
> connected using this method, but I assume this would only connect to IMAP
> servers.

yes, but for POP3, you have pop3_mailstorage_init()
you may have a look to the tests/ folder in libetpan package.
the connection is specific for each kind of connection.
For example, for a MH folder, you don't have to specify any server.

> 2)  What is the use of sessions?  I would have thought that a session
> would envelop a storage, but it seems that the storage data structure is
> what I pass to all the functions in order to retrieve messages and
> folders.  How are sessions used in libEtPan?

The use of session should be avoided in favor of mailfolder.
mailfolder.h wrap all the API of mailsession.
public access to session API is historical.

In fact, mailstorage and mailfolder are both wrappers on 
mailsession.

(Continue reading)


Gmane