More On Mime

More On Mime

[Lars Magne Ingebrigtsen]

I've now had a peek at Ray Moody's rmime.el, and I'm very impressed by
it.  By the comments in it, I mean.  I've never seen such a
well-commented package before in my life.  It seems to be doing what
it's supposed to be doing as well, so I think it can be used for my
nefarious purposes.  The problem is the copyright situation, but that
looks like it might work out.  Stay tuned.

William Perry's mm.el handles mailcap parsing well, and has lots of
MIME support functions, so I think if I basically take these two works
and squish them together (and add some more stuff), we should have
that simple MIME library with that interface I outlined earlier.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: More On Mime

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@ifi.uio.no>:

> I've now had a peek at Ray Moody's rmime.el, and I'm very impressed by
> it.  By the comments in it, I mean.  I've never seen such a
> well-commented package before in my life.  It seems to be doing what
> it's supposed to be doing as well, so I think it can be used for my
> nefarious purposes.  The problem is the copyright situation, but that
> looks like it might work out.  Stay tuned.

You plan to replace metamail with elisp stuff, I hope? (Or doesn't
rmime.el need metamail anymore? I haven't used it since my VM days
(which was before my mh-e days (which was before my (current) Gnus
days)))

> William Perry's mm.el handles mailcap parsing well, and has lots of
> MIME support functions, so I think if I basically take these two works
> and squish them together (and add some more stuff), we should have
> that simple MIME library with that interface I outlined earlier.

Nice! But when you have this we'll start an undying thread about how
we would like to see MIME stuff presented...:-)

Re: More On Mime

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> You plan to replace metamail with elisp stuff, I hope?

I think so, yes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[François Pinard]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steinar Bang <sb@metis.no> writes:
> 
> > You plan to replace metamail with elisp stuff, I hope?
> 
> I think so, yes.

For small inserts, Emacs LISP stuff does well.  For big inserts, Emacs
LISP may be irritatingly slow, even when compiled.

I would like to see options and size thresholds for being able to call
external decoders, either `metamail' or (plug! :-) the next version of
`recode', for when it will be ready for release.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: More On Mime

[SL Baur]

Fran^[,Ag^[(Bois Pinard <pinard@iro.umontreal.ca> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Steinar Bang <sb@metis.no> writes:
>> 
>> > You plan to replace metamail with elisp stuff, I hope?
>> 
>> I think so, yes.

> For small inserts, Emacs LISP stuff does well.  For big inserts, Emacs
> LISP may be irritatingly slow, even when compiled.

Yup.  I did some timing of this (wrt base64 decoding) in tm when we
were first integrating it with XEmacs.  It wasn't so much that large
attachments were slow to decode, but that funneling things through
mmencode was *much* faster.

> I would like to see options and size thresholds for being able to call
> external decoders ...

I agree.

Re: More On Mime

[Steinar Bang]

>>>>> SL Baur <steve@xemacs.org>:

> Yup.  I did some timing of this (wrt base64 decoding) in tm when we
> were first integrating it with XEmacs.  It wasn't so much that large
> attachments were slow to decode, but that funneling things through
> mmencode was *much* faster.

How well does running things through external programs work on MSWin? 

Re: More On Mime

[SL Baur]

Steinar Bang <sb@metis.no> writes:

>>>>>> SL Baur <steve@xemacs.org>:
>> Yup.  I did some timing of this (wrt base64 decoding) in tm when we
>> were first integrating it with XEmacs.  It wasn't so much that large
>> attachments were slow to decode, but that funneling things through
>> mmencode was *much* faster.

> How well does running things through external programs work on MSWin? 

I don't know.  I don't think subprocesses work yet, but they're
working on it.

Re: More On Mime

[Matt Armstrong]

Steinar Bang <sb@metis.no> writes:

> >>>>> SL Baur <steve@xemacs.org>:
> 
> > Yup.  I did some timing of this (wrt base64 decoding) in tm when
> > we were first integrating it with XEmacs.  It wasn't so much that
> > large attachments were slow to decode, but that funneling things
> > through mmencode was *much* faster.
> 
> How well does running things through external programs work on
> MSWin?

Yes, if properly set up.  Evidence: movemail.exe in the standard emacs
distrib; reports of people getting tm up and running by hacking new
versions of all the sh scripts and executables it comes with.

But a large chunk of the mail on the NTEmacs list is people having one
problem or another with shelling to external programs.  They have a
cmdproxy.exe that attempts to translate unix style command lines to NT
(e.g. "/bin/sh -c lpr" -> "cmd.exe /c lpr") -- so unix elisp code
still works.  It causes people grief sometimes.

I use NT Emacs.  I'd personally like (at least the option of) an elisp
only solution.  Unix<->Win32 portability is assured that way.  I don't
get enough attachments to make performance a big issue.

If size thresholds are implemented, setting them very high or to a
magic value (nil) would work.

Re: More On Mime

[Lars Magne Ingebrigtsen]

SL Baur <steve@xemacs.org> writes:

> Yup.  I did some timing of this (wrt base64 decoding) in tm when we
> were first integrating it with XEmacs.  It wasn't so much that large
> attachments were slow to decode, but that funneling things through
> mmencode was *much* faster.

Has there been any discussion on including base64 support in
Emacs/XEmacs proper?  It seems like a natural thing to do to me...
`base64-buffer-region' and `unbase64-buffer-region', or whatever.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[SL Baur]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Has there been any discussion on including base64 support in
> Emacs/XEmacs proper?

No.  (Not that I'm aware of, anyway).

> It seems like a natural thing to do to me...  `base64-buffer-region'
> and `unbase64-buffer-region', or whatever.

That would be a Good Idea, in my opinion.

Re: More On Mime

[William M. Perry]

SL Baur <steve@xemacs.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Has there been any discussion on including base64 support in
> > Emacs/XEmacs proper?
> 
> No.  (Not that I'm aware of, anyway).
> 
> > It seems like a natural thing to do to me...  `base64-buffer-region'
> > and `unbase64-buffer-region', or whatever.
> 
> That would be a Good Idea, in my opinion.

  Its trivial code - kyle has some stuff he put in the public domain.  I
could try sunday...

-Bill P.

Re: More On Mime

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   Its trivial code - kyle has some stuff he put in the public domain. 

And it would grow increasingly useful as MIME gets more and more
popular.  If we could get this into XEmacs/Emacs kinda fastish, we
could just use elisp compatibility functions for older Emacsen, and
let the new MIME library call these functions.  That should allow us
to not rely on external unpackers all the time.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[SL Baur]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> wmperry@aventail.com (William M. Perry) writes:
>> Its trivial code - kyle has some stuff he put in the public domain. 

> And it would grow increasingly useful as MIME gets more and more
> popular.  If we could get this into XEmacs/Emacs kinda fastish, we
> could just use elisp compatibility functions for older Emacsen, and
> let the new MIME library call these functions.  That should allow us
> to not rely on external unpackers all the time.

That's fine with me, the fastish-er the better.  The code for XEmacs
20.5 is scheduled to be frozen in early March.

Re: More On Mime

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> and squish them together (and add some more stuff), we should have
> that simple MIME library with that interface I outlined earlier.

I missed the outline, do you remember where you put it?

I suggest getting Quassia Gnus released before starting on MIME.  I'd
like to improve my standard answer when people ask for a Unix
newsreader with agent-like capabilities a little from "yes, Quassia
Gnus can do that, but it is in alpha, so you shouldn't use it."

Re: More On Mime

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> > and squish them together (and add some more stuff), we should have
> > that simple MIME library with that interface I outlined earlier.
> 
> I missed the outline, do you remember where you put it?

Nope; but it went something like this:

`emime-parse-buffer &optional BUFFER'
Parses BUFFER and returns a list of emime handles.

`emime-displayable-p HANDLE'
Says whether HANDLE can be displayed inline.  (And lots of other
predicates.)

`emime-insert HANDLE'
Inserts HANDLE at point.

`emime-display HANDLE'
Shows HANDLE in an auxiliary program.  (mailcap etc. comes in here.)

`emime-output-to-file HANDLE'
Output HANDLE to a file.

And that's basically it.  (Well...  Some support functions for dealing
with encoded strings and stuff is also needed, but, like.)  The
HANDLEs probably will be a list of things needed for emime to do, uh,
stuff, but should be regarded as opaque by other packages.

> I suggest getting Quassia Gnus released before starting on MIME.  I'd
> like to improve my standard answer when people ask for a Unix
> newsreader with agent-like capabilities a little from "yes, Quassia
> Gnus can do that, but it is in alpha, so you shouldn't use it."

Yup.  I plan on slogging through the gnus-bug messages this weekend,
and then I'm moving Quassia to Gnus 5.6.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[Lars Balker Rasmussen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > I suggest getting Quassia Gnus released before starting on MIME.  I'd
> > like to improve my standard answer when people ask for a Unix
> > newsreader with agent-like capabilities a little from "yes, Quassia
> > Gnus can do that, but it is in alpha, so you shouldn't use it."
> 
> Yup.  I plan on slogging through the gnus-bug messages this weekend,
> and then I'm moving Quassia to Gnus 5.6.

Does moving Gnus Agent out of alpha include making it deal better with
articles expired on the server?  How about making it possible to expire
local articles?  Will it be possible to make various constraints on when
an article can be expired, e.g. (read), (age > 14 days), or the more
interesting (read & age > 14 days)?
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk

Re: More On Mime

[Lars Magne Ingebrigtsen]

Lars Balker Rasmussen <lbr@mjolner.dk> writes:

> Does moving Gnus Agent out of alpha include making it deal better with
> articles expired on the server?

Not automatically, no.  :-)

> How about making it possible to expire local articles?  Will it be
> possible to make various constraints on when an article can be
> expired, e.g. (read), (age > 14 days), or the more interesting (read
> & age > 14 days)?

Good idea.  Should this be tied to the categories?  Uhm, yes, I think
so. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[Wes Hardaker]

>>>>> On 11 Feb 1998 14:42:29 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> Yup.  I plan on slogging through the gnus-bug messages this
Lars> weekend, and then I'm moving Quassia to Gnus 5.6.

You know, I was really hoping it would hook into real scoring methods
before this happened...

Hmm...  And I had so many things I wanted to implement before the end
of the alpha code.  I don't think I'll get to them before this weekend...
-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: More On Mime

[Per Abrahamsen]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> You know, I was really hoping it would hook into real scoring methods
> before this happened...

There will be life after Gnus 5.6 as well.

Re: More On Mime

[Wes Hardaker]

>>>>> On 12 Feb 1998 11:26:52 +0100, Per Abrahamsen <abraham@dina.kvl.dk> said:

>> You know, I was really hoping it would hook into real scoring methods
>> before this happened...

PA> There will be life after Gnus 5.6 as well.

Yep...  But I consider this an important feature of the agent.  I
don't think its good to separate the scoring sections into two
unrelated pieces.  I just think it would be better to roll them into
one before releasing the first public version of the agent...

That and I really really want it personally (but don't have the time
to implement much for gnus these days).

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: More On Mime

[François Pinard]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > I missed the outline, do you remember where you put it?

> Nope; but it went something like this [...]  And that's basically it.

I cannot really foresee, from the outline, how flexible will be the
interface as the Gnus user will see it.  Surely, one has to be able to
assemble an outgoing message from parts, and needs ways to handle parts
separately in a received message, maybe borrowing to the usefulness of
the `undigest' features.  The Gnus user interface has to be well-thought
(:-) when going to read mode to edit mode, either replying to a message
(there are a lot of ways to reply) or directly editing a received message.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: More On Mime

[Lars Magne Ingebrigtsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

François Pinard <pinard@iro.umontreal.ca> writes:

> I cannot really foresee, from the outline, how flexible will be the
> interface as the Gnus user will see it.

Once the basic MIME library is in place, we can start experimenting
with user interfaces MIME stuff from Gnus.  That's one of the reasons
I want to keep the MIME programming interface very, very simple, so
that we can do lots and lots of, uh, stuff.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[Per Abrahamsen]

Nice.  I have been thinking about it from a customization point of
view, i.e. how to specify methods for handling each content-type.


emime-standard-methods
	General methods provided by the mime library

emime-mailcap-methods
	General methods parsed from the mailcap file

emime-user-methods (customizable)
	General methods specified by the user.

emime-aplication-standard-methods
	Extra methods specified by the application (i.e. Gnus, W3, RMAIL).

emime-application-user-methods
	Extra methods specified by the user for this application only.

When the mime library want to handle a particular content type, it
should look through all the above.  The latest taking priority.

The individual applications would bind
`emime-aplication-standard-methods' and
`emime-application-user-methods' before calling the library.  E.g.

	(let ((emime-aplication-standard-methods gnus-emime-standard-methods)
	      (emime-application-user-methods gnus-emime-user-methods))
           (emime-handle handle))

Maybe there should be separate variable for internal and external
display of content.

Maybe the priority of the mailcap methods have to be more detailed
than the above.  I believe you can specify application specific
methods in mailcap as well.

Re: More On Mime

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Nice.  I have been thinking about it from a customization point of
> view, i.e. how to specify methods for handling each content-type.

[...]

> When the mime library want to handle a particular content type, it
> should look through all the above.  The latest taking priority.

Yup; sounds like a plan.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More On Mime

[Justin Sheehy]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Yup.  I plan on slogging through the gnus-bug messages this weekend,
> and then I'm moving Quassia to Gnus 5.6.

Hmm.

Now, I admit that I can't talk much here, because I wanted to work on
this part and haven't had time to, but...

Hasn't part of the standard line been that IMAP support would be in
5.6?  Is anyone actively working on this?

I have lots of ideas, but admittetdly have done very little actual
code tinkering with this.

I have been asked by several people when there will be a good IMAP
client.  There are people that _really_ want IMAP but are being forced
to choose between IMAP and Gnus.

It really is a tough choice.

And btw, an IMAP implementation that acted pretty much like POP would
not in any way solve these issues.  I, and others, want two major
things out of IMAP:

1) The ability to deal with the same message store cleanly from a
   local client in several different places.  POP does not solve this
   problem.  NFS definitely does not solve this problem.  IMAP is
   really the only way that I can see to elegantly achieve this.

2) Real disconnectedness.  I think that there may be some conflicts
   between the "agent" sense of disconnectedness and the IMAPish way.
   I'm not sure though, as I haven't played much with the nnagent
   stuff.

-- 
Justin Sheehy

In a cloud bones of steel.