Re: nnimap URLs? (Was: What now?)

[wmperry@aventail.com (William M. Perry)]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Simon Josefsson <jas@pdc.kth.se> writes:

> William M. Perry <wmperry@aventail.com> writes:
> 
> > I'm not sure if I know enough about the guts of 'imap.el' to hack this
> > together or not.  Fortunately, it is easy to add a new URL type. :)  If
> > anyone (simon?) wants to work on this, let me know and I'll concentrate on
> > getting the documentation on how to do this written tonight.  I would LOVE
> > to see this get written.
> 
> If there is a url-nntp.el to look at I could have a go at it.

This is a work-in-progress, but should be a good starting point.  Will this
be able to be asynchronous?  I noticed there was an imap-fetch-asynch call,
but I didn't see how it ever got a callback or anything like that handed to
it.  If it is, you need to add:

(defconst url-imap-asynchronous-p t "IMAP retrievals are asynchronous.")

And the url-imap routine would get a callback and a cbargs argument that it
is expected to call with the current buffer set to where the article is.
If there is no data to return, it just never calls the callback.

If nil is returned (or the callback is not activated), then that means
there is no real data to return (ie: someone did imap://mail.server.com/
and we just go straight into gnus) to the calling app.

Basically, the new URL stuff expects a buffer to look like a MIME message,
with headers intact at the top, including a content-type and content-length
when available.

Any questions, lemme know.

-Bill P.


[-- Attachment #2: url-news.el --]
[-- Type: application/emacs-lisp, Size: 5031 bytes --]

[-- Attachment #3: url-imap.el --]
[-- Type: application/emacs-lisp, Size: 1499 bytes --]