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

List:       kde-core-devel
Subject:    Re: Some pop3 kioslave enhancements
From:       Alex Zepeda <jazepeda () pacbell ! net>
Date:       2000-01-08 21:31:12
[Download RAW message or body]

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.

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

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

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

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

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


- alex

Experience something different
With our new imported dolly
She's lovely, warm, inflatable
And we guarantee her joy
  - The Police

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