mime API is inconsistent

[rsc]

probably ParseMediaType should split the type in half.
it is easier to write x+"/"+y than to take "x/y" apart.


---------- Forwarded message ----------
From: devil <jdevilliers@gmail.com>
Date: Thu, Oct 27, 2011 at 02:30
Subject: [go-nuts] mime media type manipulation
To: golang-nuts <golang-nuts@googlegroups.com>


Hi

I am am doing some work that requires me to take apart mime media type
values, possibly change some of the parameters, and then put the whole
thing back together again. To this end, the go mime package provides 2
functions, namely

func ParseMediaType(v string) (mediatype string, params
map[string]string, err os.Error)

 and

func FormatMediaType(t, sub string, param map[string]string) string

Unfortunately, FormatMediaType requires the media type value to be
broken down into a type and a subtype, while ParseMediaType returns a
single string containing the type and subtype.  Of course it is not
rocket science to do that bit of manipulation myself, but it would be
more convenient (to me, at least :-) if these two functions were
consistent with each other.

Regards

Johan

[rsc]

Comment 1:

Labels changed: added priority-later, removed priority-medium.

[rsc]

Comment 2:

Labels changed: added priority-go1.

[bradfitz]

Comment 3:

This is easy enough to fix, but lately I've been thinking of doing something like:
package mime
type Type string
func (t Type) Type() string  // major type
func (t Type) Subtype() string
func (t Type) Params() map[string]string
func (t Type) Param(p string) string
FormatMediaType(t, sub string, param map[string]string) Type
or Type as a struct, if using a string is not desirable.  But it's a simple enough
format & small string, easy to scan for boundaries.
Thoughts?

[rsc]

Comment 4:

Is there no escaping at all in the parameter encoding?

[bradfitz]

Comment 5:

Yes, but rarely. Usually there's only zero or one parameter in practice.  And there's a
nice fast path for saying that a parameter doesn't exist:  !string.Contains(string(t),
p)  I don't think we'd have to do too much repetitive parsing of the parameters.
If callers were actually performance sensitive, they can call Params() and get them all
at one.  I doubt most callers would care, though.

[rsc]

Comment 6:

Is it case-insensitive?

[bradfitz]

Comment 7:

No, I guess not.  From our existing docs:
"The returned map, params, maps from the lowercase attribute to the attribute value with
its case preserved."
So I guess it's a bit harder than string.Contains, but not much.  It's always ASCII, at
least, making a little containsFold(s, sub string) bool function in the mime package
easy & fast, if that's what you're concerned about.

[rsc]

Comment 8:

the Type Type doubling bothers me but otherwise ok.
the rfcs say top-level type and subtype.
maybe name the methods TopLevel and Subtype?
separately, what do you do if you want to make
the type for "image/jpeg" with a paramter?
do you have to pick apart "image" and "jpeg" first?
that's kind of lame.
how often do people care about the two halves of
the type?  another possible api is
func BuildType(media string, params map[string]string) Type
func (Type) Media() string
func (Type) Param(name string) string
func (Type) Params() map[string]string
func (Type) String() string
?

[gopherbot]

Comment 9 by jdevilliers:

i submitted the original request and, for what it is worth, i don't really care about
the two halves of the type at the moment. other users might care, though.
my application is very performance sensitive, so an api that does too many internal
string operations that i have no control over would be a problem.

[rsc]

Comment 10:

what mime-manipulation operations do you need in your application?

[robpike]

Comment 11:

Owner changed to builder@golang.org.

[bradfitz]

Comment 12:

I never noticed that this submit failed.
http://golang.org/cl/5539048/
Re-running tests & submitting again.

Owner changed to @bradfitz.

[bradfitz]

Comment 13:

This issue was closed by revision a00de45.

Status changed to Fixed.