efficiency vs usability

[stewie]

I just read https://github.com/warren-bank/moz-rewrite/blob/js/data/recipe-book/request/light%20weight%20ad-blocker.js where you comment on the inefficiency of building an array each time a fn is called. Isn't that approach necessary (efficiency be damned) when an extension needs to accommodate on-the-fly user changes, via ticking and unticking checkboxes in gui?

I'm in awe of your moz-rewrite code. It's so technically perfect, yet so perfectly unusable, that I want to cry (or pull my hair out, or)

I recognize that you've improved and extended the methodology of https://github.com/loreii/HeaderTool but I landed here hoping to find a "clue" toward modding the existing "ModifyHeaders" extension and adding ability to use it, via gui, to setup rules for marshalling response headers

Beyond a handful of json-loving codemonkies playing with it, how do you anticipate the moz-rewrite "rules engine" will be used? Might an existing addon (RequestPolicyContinued, policeman, AdblockEdge) call it via a bootstrap profile-after-change observer?

[warren-bank]

the way I see it is that anybody who's technically proficient enough to be interested in modifying HTTP headers will most likely be a web applications developer (not a code monkey.. which is a term that's analogous to being a script kiddie).

the tool is written in such a way that its input needs to be data, and this data configures the behavior of the tool.

personally, I'm more interested in advanced functionality.. than I am in GUI. I can't picture what a GUI would look like that could support the format of the input data.

• one variation wants JSON, so it would need to be some kind of JSON editor
• one variation wants Javascript, so it would need to be some kind of JS editor

either way, personally, I would be much more comfortable writing and maintaining this kind of data in my trusty text editor. I would assume that other developers would agree. The addon preferences allows the file path of the input data files to be "watched" for changes, which is useful while writing/testing new rules. And when the rules are final, the "watch" should be turned off.. for performance sake.

as for how such a tool could be useful in conjunction with other addons.. I can only speak from my own personal experience. In the short time that I've had this addon, I've found MANY uses for it. The purpose of the "recipe book" is to share more common use-cases.. though they aren't necessarily intended to be copied verbatim. For example, the way I use the tool to normalize "content-type" response headers.. from anything that ends in "+json" to "application/json" could be used with any JSON viewer addon.. not just the one that I wrote.

if all that a user wants to do.. is to emulate the functionality of "ModifyHeaders", then the input data (for request rules) is so simple that even a non-technical user should be able to figure out how to make it work.

in any case, the project is GPLv2 for a good reason.. I welcome ideas.. and forks.. and pull requests.. and any constructive input that anybody out there in user-land has for enhancements.

heck.. there's already a ton of branches.. each having a variation on its purpose and implementation. Maybe there's room for another branch.. for a version that is less functional, but has a more user-friendly UI. I'll be honest, it isn't on my roadmap.. but I'd be open to the idea.

[warren-bank]

PS: in response to your comment about how the addon responds to updated user preferences..

for this particular addon, any change in user preferences could potentially invalidate everything.. so I took a fairly simplistic approach. There's an observer that is notified whenever a user preference (under the branch owned by this addon) is updated. When this occurs, the addon shuts itself down, cleans up all of its data objects, waits for a second, then re-initializes itself.

The initialization step uses the current state of the user preferences (ex: path to data files, whether or not to watch them, etc). I'm fairly certain that none of the preferences are queried after initialization.. as requests are intercepted and processed.

note: the preferences dialog notifies the preferences observer only once, after the user clicks "OK" to accept the updated values and close the dialog. On the other hand, manual edits via about:config trigger the observer for each change.

PPS: efficiency and performance always matter! ..they're never just an after-thought.. or a final sprint; IMHO, they should always be a part of the design from day one. (just saying)

[warren-bank]

PPPS: regarding "HeaderTool"..

I like what Lorenzo did. He's a good guy, and I wrote a pretty glowing comment on his AMO page.

That being said, the only code shared between the two projects is his crypto() function, which I openly admit that I "borrowed" :grinning:

..which, truthfully, is really just a thin wrapper around a standard API call

[warren-bank]

tell you what..

first thing on my plate is to implement the new branch: js/Cu.evalInSandbox/master.. which currently shares the same commit SHA as js/eval/master. I need to refactor the code and use the Cu.Sandbox APIs. That's priority 1.

after that.. I'm thinking I should probably create some kind of screencast tutorial.. to demonstrate how to use this tool. I think once people, who are technically savvy but may not see exactly how all of the pieces fit together based on the documentation that tends to be a bit (overly?) verbose, see it in action.. and how simple it is to use.. and how powerful it can be.. that it would go a long way to explain the what/how/why of it all.

this is all still very new.. please bear with me :grinning:

[warren-bank]

updates..

• regarding the js/Cu.evalInSandbox/master branch:
  • v1.00 was commit yesterday
  • it was submit for review on AMO, and has already been accepted for hosting
• regarding your request for a version that has fewer features, but a pretty UI.. along the lines of "Modify Headers":
  • I forked "Modify Headers", and added a "response" branch. The purpose of this branch is to use the exact same UI as the official version, but to apply the updates to RESPONSE headers.. rather than REQUEST headers
  • v1.04 has been published, and an .xpi addon is attached to the tagged release
  • the 2 addons can run side-by-side
  • the official one, that modifies request HTTP headers
  • this unofficial fork, that modifies response HTTP headers
  • enjoy! :grinning:

[stewie]

"I should probably create some kind of screencast tutorial.. to demonstrate how to use this tool."

For some people, a screencast would make things click. For other potential users, real-world working examples would probably be the clincher. ("How do I defeat no-cache directives?" is the first example which springs to mind)

The ModifyHeaders extension contains quite a bit of outdated code. Once reworked, an analogue targeting response headers would probably stand better as a fresh project than as a "fork" of MH. Although I'm hacking at it, I don't have a goal of publishing/documenting a working extension. I do like the UI (sortable tree columns, moveUp/Down buttons) but, yeah, I hear ya about "hard to imagine a UI that could expose all the moz-rewrite functionality". Check the pull requests -- someone already added accommodation of regex matching "patterns" -- but that's just the tip of the iceberg. Ultimately, I think MH focus is too header-centric; to be effective, the I believe the approach would need to be rules-centric. In any event, although Proxomitron has a "header filter editor" UI, I can't guess "how much more accessible" that UI made proxo seem, in the eyes of non-technical users. Personally, I would have encouraged most users to edit its config file directly -- much easier to learn by example that way, scrolling to view the details of the existing filters.

From an IANA reference page, I scraped a list of established, and provisional, response header names (about 180 total) and stuffed those into the "autocomplete" pref of the would-be ModifyRESPONSEheaders extension. Naw, I realized, the autocomplete is a whizmo feature rather than a useful one. Really, what the user needs is a prepopulated (but editable) lookup of names AND expected/common/typical values AND an indication whether declaration of multiple/merged values are permissable for a given headername... and probably an additional freeform notes/comments field per item as well.

For my intended use, a further "flagged" field per item (I'm thinking in terms of per rule, rather than per headername) will be necessary. I'm shooting for: "display, per tab, an infobar when any flagged rule is matched" and/or when any never-seen-before, uncataloged, headername is encountered. Clicking any displayed URI+headername+value infobar entry will launch a LiveHTTPHeaders window, or equivalent. If I manage to get it working, I'll send up a zipfile for your critique.

[warren-bank]

would probably stand better as a fresh project than as a "fork" of MH

I chose to fork for 2 reasons:

• assign credit (and/or blame) where it's due
• having the ability to diff (my commits) against the original code

That being said, after I pushed the commit (and tagged release) for v1.04.. and shared the .xpi with you (here, in this issue's comment thread).. I decided that there's probably others who may find the forked version useful. I chose to submit it to AMO for review.. ultimately for the purpose of having a copy hosted there.

To be perfectly honest, I spent a fair bit of time researching what the proper etiquette is.. for how to list the original author (and give him proper credit) vs. how to list myself as the author of the modifications.. within the "install.rdf" file. I kind of hate listing myself as "creator".. that seems so wrong (to me) to do.. and yet that field is intended for display within the addon's "about" dialog. As such, from what I could find online regarding the topic.. it seems that the correct thing to do is to list myself as "creator".. and I included the original author as a "developer". Then within the description, I immediately clarified that this is a fork.. and gave links to the original source material. I hope that's sufficient. I'd hate for anybody to think that I'm trying to claim "credit" for writing this addon. As the commit diff shows, all I did was 2 minor code changes (to make it work with RESPONSE, rather than REQUEST) which took about 5 minutes.. and a whole bunch of multi-file search/replace operations (to prevent the addons from stepping all over each other when both are installed together) which took significantly longer.. about 2 hours or so. Obviously, the time I spent doesn't compare to the time the author (presumably) spent to write the original code base.

[warren-bank]

"How do I defeat no-cache directives?" is the first example which springs to mind

that's a very good idea for a "recipe"! I'll add that to my "to-do" list.. thanks :grinning:

[warren-bank]

as for making enhancements to "Modify Headers".. giving it more powerful capabilities.. that was never my intention.

all I wanted was a quick fix that I can point to when somebody asks me to give "moz-rewrite" a pretty UI ("just like MH").

now they have the option:

• text-based with powerful capabilities
  • "moz-rewrite"
• UI-based with simplistic capabilities
  • "Modify Headers"
  • "Modify Response Headers"

That being said, maybe the enhancements that you're working on could help bridge the gap. I'd be glad to glance over any of your commit diffs. I wouldn't consider myself an expert on MH's code.. I mostly just grepped through it.. though from what I saw (mainly the "service" component).. it seems pretty straight forward.