RE: [SM-DEVEL] extending decodeBody functionality

[p d. t. <pdo...@an...>]

Hey folks, 

  Thinking this over, I am ready to just commit a modified version of
Seth's patch to add this as a hook.  This is another thread that is
about to "just die", so if there are no takers, I'll just make the
commit.  I'd like to especially hear back from anyone who thinks the
hook should not be added to STABLE.  Otherwise, it's just going in...
;->

  Thanks,

    Paul


> > If we use the patch I posted earlier, I can modify the get_uuencode
> plugin
> > fairly easily.  It already handles standard and base-64 encodes.
> 
> Seems like a good idea (Seth's hook idea), as long as no one thinks
it's
> going to take a heavy hit (considering that the hook won't be used
very
> much).  If we move ahead with it, I would suggest that we adapt the
hook
> call to actually pass and retrieve the $encoding_handler array
> explicitly rather than just globalizing the thing.
> 
> 
>   - Paul
> 
> 
> > Seth.
> > Ryan P Linn said:
> > > The patch in the tracker would work in all cases except for one
that
> I've
> > > seen.  There is some windows mailer (windows is the best I could
get
> for
> > > what email client the person is using) that is using a different
> version
> > > of
> > > the x-uuencode than what most clients use.  Their implimentation
is
> to
> > > base64 the uuencoded data causing an additional check/step to be
> added to
> > > that patch.  Adding it to the core is fine, but I'm guessing at
some
> point
> > > another odd mailer will come up using another of the x- mime
> encoding
> > > types
> > > which is why I'm guessing that I was told that you guys would want
> this to
> > > be a plugin.
> > >
> > > This is not really a big deal, I have no problem continuing to add
> this to
> > > the releases that I deploy of SM but I mostly thought that if I
was
> seeing
> > > this problem then others would as well.  If you guys tell me what
> method
> > > you'd like this to be deployed in I'm more than willing to write
it,
> just
> > > point me in the direction that you want it to be taken.  If its
not
> > > something that there is interest in persuing then that is ok as
> well.
> > >
> > > Thanks in advance for the feedback,
> > > -Ryan
> > >
> > >
> > > On Sun, Sep 21, 2003 at 01:10:25AM +0200, Marc Groot Koerkamp
wrote:
> > >> There is a patch for uuencode present in the patches tracker. I
> think
> > >> it's
> > >> better to put it in core if the patch I'm refering at does the
job
> then
> > >> using a plugin for that.
> > >>
> > >> Marc.
> > >>
> > >>
> > >>
> > >> p dont think said:
> > >> > All,
> > >> >
> > >> >   Got the message below yesterday, and after talking it over
with
> > >> Ryan,
> > >> > I think there is no way to make SM aware of a new encoding type
> except
> > >> > to change the source or create a new hook.  The questions,
then,
> are:
> > >> > what do people think of adding x-uuencode decoding to the core?
> If it
> > >> > seems too obscure, is the cost of a hook in decodeBody worth
it?
> Ooo,
> > >> > if it was done as a hook, we could use Chris' new boolean hook
> > >> function
> > >> > to ask plugins if they handled the encoding or not.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> >   - Paul
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Ryan P Linn [mailto:rp...@un...]
> > >> > Sent: Thursday, September 18, 2003 1:38 PM
> > >> > To: pdo...@an...
> > >> > Subject: Plugin Question
> > >> >
> > >> > Hello,
> > >> >   I was trying to figure out how to port code that I wrote
> designed to
> > >> > go
> > >> > into core SM to a plugin and was hoping that you might be able
to
> > >> help.
> > >> >
> > >> > There is currently an additional encoding type that I need to
> support
> > >> > for
> > >> > my users, x-uuencode.  I'm having a lot of trouble finding an
> > >> > appropriate
> > >> > hook for this as the attachment is seen its just not decoded
> because
> > >> the
> > >> >
> > >> > encoding type isn't quoted or base64.  I looked at message_body
> and it
> > >> > didn't seem to fit there because only inline attachments in
text
> look
> > >> > like
> > >> > they would be processed there and the attachments_bottom
doesn't
> look
> > >> > like
> > >> > that fits well because at that point the attachment has already
> been
> > >> > displayed to the attachment box.  The attachment type/type hook
> > >> doesn't
> > >> > seem to be the one that I would want to use because the end
type
> is
> > >> > correct, its just the encoding thats wierd.  The part where
this
> > >> seemed
> > >> > to
> > >> > fit in best in the core was in the decodeBody function in
> mine.php
> > >> since
> > >> >
> > >> > the only thing that has to happen is for the different encoding
> to
> > >> kick
> > >> > in.
> > >> >
> > >> >   Sorry that was so long.  Thanks in advance for any advice you
> may be
> > >> > able to give on this.  I've been stuck for a few days and have
> working
> > >> > code that I'd like to contribute back but the feeling seemed to
> be
> > >> that
> > >> > people would rather this be a plugin than in the core since so
> few
> > >> > mailers
> > >> > use this type of encoding.
> > >> >
> > >> >
> > >> > Thanks again for your help.
> > >> > -Ryan
> > >> > k
> > >> >