From kde-core-devel  Tue Dec 28 12:35:30 1999
From: Don Sanders <dsanders () cch ! com ! au>
Date: Tue, 28 Dec 1999 12:35:30 +0000
To: kde-core-devel
Subject: Re: Some pop3 kioslave enhancements
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=94638438423798

On Tue, 28 Dec 1999, Alex Zepeda wrote:
> On Tue, 28 Dec 1999, Don Sanders wrote:
> 
> > I have extended slotGet in the pop3 kioslave, the following commands are now 
> > supported.
> > 
> > URI                                
> >  Command   Result
> > ---------------------
> 
> > pop://user:pass@domain/index       
> >  LIST      List message sizes
> > pop://user:pass@domain/uidl        
> >  UIDL      List message UIDs
> 
> 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.

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.

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).

> 
> > pop://user:pass@domain/download/#1 
> >  RETR #1   Get message header and body
Just documenting existing functionality.

> > pop://user:pass@domain/list/#1     
> >  LIST #1   Get size of a message
> 
> Eek no, don't do that.  There's already a getsize method common to all
> ioslaves.
I have no problem with getsize.

> > 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.

> > 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 
...
      job->listDir( mUriForAccountnOnMailServer );
      job->kill();

Despite it being ugly I can see no superior alternative. I don't consider a 
custom kioJob superior, I consider it unnecessary complexity.

> > pop://user:pass@domain/headers/#1  
> >  TOP #1    Get header of message
> 
> Also, for all those that do only parts of a message,
headers was the only one I believe.

> my indended goal was
> to use ? style parameters so that you could do:
> 
> pop://host/1?show=headers-only
I see. In that case it would be nice to compliment this with
pop://host/1?show=uidl

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.

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.

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.

BFN,
Don.