[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: Some pop3 kioslave enhancements
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       2000-01-10 6:44:20
[Download RAW message or body]

On Sun, 09 Jan 2000, Alex Zepeda wrote:
> On Tue, 28 Dec 1999, Don Sanders wrote:
> 
> > > Eeek.  No.  This should be exposed with just pop://user:pass@host/ and a
> > > few custom directory atoms or whatever they're called.
> > Well I only added the uidl one, the index one was already there. I extended the 
> > idea towards its natural conclusion.
> 
> Some of what I put in there was based on my first try, and I forgot to (or
> was too lazy to) delete it, and should be removed.
> 
> > I was using a slotListEntry based implementation in kmail, which I
> > guess is a directory entry based approach. I just threw it away as it
> > was a mess, extending get makes things simpler, on both the slave and
> > the client side. This was my motivation for the change.
> 
> How so?  For getting headers and such it seems rather simple.

It is reasonable simply. Define a slot for getting individual directory entries.
Call KIOJob::listDir. Have the slot iterate over the KUDSAtoms in the KUDSEntry
passed in, until the UDS_NAME atom is found, then append that to a list of
message ids. (Or at least that's the way I remember it).

But it's significantly simpler to process the raw data returned from the pop
server. (Which is a CR seperated string of msgId-space-msgSize lines).

If I start to support IMAP then perhaps I would swap over to using listDir if
it means I could reuse the same source code for both pop and imap accounts.
(I guess IMAP listDir would return subdirectories for subfolders and pop would
never return any subdirectories).

> > Having said that I was worried that people would find extending get
> > conceptually displeasing, I can see that this is the case.
> 
> > > > pop://user:pass@domain/remove/#1   
> > > >  DELE #1   Mark a message for deletion
> > > 
> > > Eek, no.  There should be a delete method too.
> >
> > Just documenting what had always been there. (There is the question of
> > whether the delete method, slotDel, should close the connection to the
> > server or not).
> 
> POP3 is a PITA, and I think what should happen is that it should mark the
> message for deletion.  And optionally close the connection, then attempt
> to reconnect.

Well if it' s possible to change the method to optionally support closing the
connection that would be nice. Best to default it to close the connection like
it currently does I think.

> > > > pop://user:pass@domain/download/#1 
> > > >  RETR #1   Get message header and body
> > Just documenting existing functionality.
> 
> Again, see above, this was my first attempt.  Altho if anything I think
> that download and #1 should be switched so that the path looks like
> /#1/download.

Or maybe drop the download part all together, (actually maybe this is already
supported).

> > > > pop://user:pass@domain/uid/#1      
> > > >  UIDL #1   Get UID of a message
> > > 
> > > Again, another custom directory entry (inode perhaps) should be used here.
> > 
> 
> > How would that work? I don't necessary want to list all entries in a
> > 'directory' to see the uid of a message. Eventually I want to support
> > leaving the bodies of messages over x bytes in size on the server. In
> > order to that (efficiently which is the whole point) I need to have
> > random access to a uid of a particular message number.
> 
> Ehm.  Well, I think that this should be included in the directory listing
> anyways (and thus another custom UDS entry type). 

Sure that sounds fine, (I'm dong ok without using listDir at the moment
though).

> But then if you want
> random access my favorite idea is using http style arguments so that you
> could string together a bunch of them and do something like:
> 
> pop://user:pass@host/#1?body=true&headers=false&uid=true
> 
> > > > pop://user:pass@domain/commit      
> > > >  QUIT      Delete marked messages
> > No complaints here? Now that was an ugly hack to close the connection to the 
> > server. Still it's an improvement over the my previous method 
> 
> Well I don't like *either* of the POP3 or IMAP4 protocols and the way that
> they make integrating them with a konqy or mail client like concept are a
> PITA, needlessly.
> 
> > Despite it being ugly I can see no superior alternative. I don't consider a 
> > custom kioJob superior, I consider it unnecessary complexity.
> 
> But if it's being reused by other mail programs....

Maybe general support for connection oriented protocols exposing
additional open and close methods is the way to go here, (did Waldo suggest
this?). If other people want to use this I'll jump on the bandwagon, and
start using it too.

> > > pop://host/1?show=headers-only
> > I see. In that case it would be nice to compliment this with
> > pop://host/1?show=uidl
> 
> Yes, something like this.
> 
> > I have code based on these extensions that works. This approach is
> > simpler than a directory based approach, both on the slave and the
> > client side. I just added pretty efficient "only retrieve new mail"
> > code to the client using uids, it was only half a dozen lines.
> 
> Ok.
> 
> > Conceptually it is ill fitting, from a certain point of view. But from
> > another point of view the pop protocol if screwed and trying to gloss
> > over this fact with unnecessary code is futile.
> 
> Conceptually neither the pop or imap were really designed to be used this
> way which means what we're trying to do is like shoehorning a car tire
> onto a unicycle.

The main problem I have with the kioslave at the moment is that when an error
occurs the slave hangs rather than calling slotError. Sticking a "finished();"
in between pop3_close() and return in the code below half fixed the problem.
(It stops the hanging but doesn't cause slotError to be called, maybe I
should try to put a call to error in there instead). 

      fprintf(stderr, "Couldn't login. Bad RETR Sorry\n");
      fflush(stderr);
      pop3_close();
      return;

> > I have no problem with slotListEntry being extended with extra
> > attributes, (it doesn't solve all the outstanding problems though). I
> > hope we can leave the extensions in.

I still feel the same way here. But would change my mind if a consistent KIOJob
like API could be created for both pop and imap accounts.

BFN,
Don.

[prev in list] [next in list] [prev in thread] [next in thread]