747315 - Port FeedSniffer to JS

Status: RESOLVED INACTIVE

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[Asaf Romano (gone)]

The feed-sniffer is a very lean component, which only uses scriptable xpcom stuff. It could therefore be ported to JS easily.

Comment 1

[Asaf Romano (gone)]

Attachment: works, but not landable as-is

When I raised this issue in the other bug, I didn't consider a couple of things:
1) This code is called for *every* request
2) c++ implementations benefit from using nsDependentString on the 

Each of these issues on its own is not a problem, but together they could hurt performance: we'll copy-and-transform a potentially large bytes array for every request. For the simple case, in which the data is not encoded, we could cut the bytes array earlier, but for the gzip case I don't think there's much we can do.

So, I'm not sure if this is a deal-breaker or not, but it sure might be. Gavin, my request for feedback is mostly for this issue.  Otherwise there's some cleanup I need to do (and probably fix some typos in the encoding-case, which I have not tested yet) ahead of a full review.

On a side note, the |String.fromCharCode...join| solution is not my final proposal here either way. Given that this code is perf-sensitive, using the unicode-converter is probably the way to go *iff* we decide to make this trade-off.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 617220 [details] [diff] [review]
works, but not landable as-is

I also failed to realize how often this was being called; I think having this code run in a hot pageload path probably precludes using xpconnect/JS. Might be interesting to push it to try to try to see what impact it would have on our Tp tests (if any!).

Comment 3

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.