[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 8.3.4: comma separated?! app:accept
* James M Snell <jasnell@xxxxxxxxx> [2007-03-13 23:00]:
> Thomas Broyer wrote:
> > [snip]
> >> The third line condenses the list to remove any duplicate or
> >> more specific equivalent entries (e.g. "image/png, image/*"
> >> becomes simply "image/*")
> >> Where's the excess complexity?
> > In the fact the above code has a bug.
> Yep, that's a known limitation that's been on my todo list for
> a while. Given the infrequency in which one finds commas in
> media type parameter values, not accounting for that case made
> A known limitation != increased complexity.
You make no sense. Let me paraphrase.
Yep, that’s a known limitation that I didn’t find the time to
fix because it is too difficult to do correctly, considering
how infrequent the problem is.
The fact that I didn’t implement it right away because it’s
not trivial != increased complexity.
Sorry, it is *exactly* a demonstration of why microparsing is
If app:accept were allowed to appear multiple times, each of
which contained only a single media type, then your code would
already be working correctly with no further effort on your part;
one todo list item you could forget about.
If *you* didn’t take the time to implement this correctly, and in
Abdera of all places (AtomPP reference implementation of the
ASF)… do I even need to spell out the question?
> > [snip]
> > For an accurate media-ranges parsing algorithm (it has not
> > yet proven to have bugs), look at httplib2.
> Note that this code does not parse the media type. It just
> splits them. I pass the parsing of the media type off to
> whatever Java Activation Framework implementation is available.
> Also note that the difficulties in parsing media type params
> does not go away when using multiple accept elements.
No, but that’s a red herring. The difficulty we’re talking about
is not parsing media type params, it’s telling apart the elements
of a list of media types. And that difficulty *does* go away when
you fix the content model. Unsurprisingly, of course, because
that’s exactly the value that XML is supposed to provide: One
Parser To Rule Them All.
app:accept as specified is CSV in XML. That’s worthy of a
DailyWTF article right there. Why do you insist on defending it?
Aristotle Pagaltzis // <http://plasmasturm.org/>