[dev] Re: [cvs] commit: whups common.php cvs.php diff.php ...

[Anil Madhavapeddy]

On Thu, Dec 21, 2000 at 12:31:17AM -0500, Chuck Hagenbuch wrote:
> 
> I'd like to discuss this with you. One of the messiest areas of Horde/IMP
> right now is MIME stuff and how it's all tied together. I'd like to figure
> out a nice way to abstract it from the IMAP layer, so that other apps that
> need to display content can do so.
> 

Sounds good.  I've never really ventured forth and looked at IMP's
MIME code - some things you just never do before dinner <g>.
I just had a quick look, and will state my idea of what we want the
handler to do.

o Figure out a given file's MIME-type (this isn't needed for IMAP,
  but is for the CVS viewer, and potentially others)

o Given a MIME-type and an input stream, be able to perform a
  'viewing' action on it, and a 'saving' action.  The viewing 
  action could be [word|excel]->html, pretty-print a GPG signature,
  etc.  'saving' is just that.  Only other thing I can think off
  is to provide a nice icon to display it.

o Potentially, derive a class of the object: is this MIME type
  an image, a video stream, text, sound, etc, irrespective of what
  _exact_ type it is.  Would be very useful for the CVS viewer;
  if it's text it would kick in a human-readable diff; if it's an
  image it would show them side-by-side so the differences can be
  visually seen, and so on.

o Have knowledge of a good range of common MIME-types, and allow
  the user to configure viewers for it.  We can rip a lot of this
  from IMP and Apache.

> One thought that came to mind was to have a generic Mime_Content object.
> This object would have a fetchContent() method. Before calling
> fetchContent(), you would need to set two parameters - $fetchMethod, and
> $fetchParams. $fetchMethod would be the name of the method to call to get
> the content, and $fetchParams would be an array of the arguments to that
> method.

I'm not entirely sure I see what you mean:  if the class has 
information on all known MIME types (or a good range of them),
and the user has configured Horde appropriately (with viewers),
then why would we need to set the two parameters? 

I suspect I'm off-track in my understanding here, so I'll let
you confirm/correct before launching off :)
 
> Another possibility is just to have the Mime_Content constructor take the
> data of the part as a parameter.

I ran into this problem with CVSLib - if the cloning of CVSLib_file
occurs in the constructor, then it can't really return a CVSLib_error
object as part of it.  So we're somewhat limited if we use the 
constructor.  Of course, it depends what kind of code style is
wanted:

(if the constructor does lots of stuff then:)

$a = Funky_Horde_Object($param1, $param2);
switch ($a->checkErrorFlag()) {
   case HORRIBLE_FAILURE:
     break;
   case SUCCESS:
     break;
}

or if the constructor is a dumb one:

$a = Funky_Horde_Object();
switch ($a->actuallyDoStuff()) {
    case xxx:
    case yyy:
}

Actually, there isn't that much in it, looking at that, but
consistency would be good.

Anil