Viva choice! Posted in Bugzilla, Mozilla, Syndicate | 2 Replies Bugzilla for Humans, II Then, you will be able to search Bugzilla using the search engine which provides the best experience in your locale.
In the future, I may create a Bugzilla extension which allows users to fill the fourth tab on the search page with the search engine of their choice, perhaps leveraging the OpenSearch standard. (To do this, obviously, you will need a copy of GreaseMonkey.) It looks like this:
As of today, December 1st, by installing this GreaseMonkey script, you can now search Bugzilla with Yahoo! Search. Therefore, I have decided to add a sixth option for those who want it. I, however, having caught the mood of the times, feel that Mozilla is all about choice, and there is still not enough choice in Bugzilla search. Some Bugzilla developers have sympathy with that view. It has been argued that this is too many, and that we should simplify the options available – perhaps building a search which is all three of Instant, Simple and Quick, instead of just one of them. The Bugzilla team is aware that there are currently 5 different methods of searching Bugzilla (as explained in yesterday’s presentation) – Instant Search, Simple Search, Advanced Search, Google Search and QuickSearch. Posted in Bugzilla, Hacking, Mozilla | Leave a reply Search Bugzilla with Yahoo! Earlier today, the api-dev VM was finally powered down. After a few false starts, requests to are now served directly by BMO, via that shim code.
#Bugzilla gmail code#
Over the intervening years, BMO itself acquired a REST API which slowly became more capable, and then a BzAPI-compatible API shim was implemented on top of it by the excellent dkl, so people could change their code to access BMO directly just by updating the endpoint URL. At its peak, it serviced 400,000 requests per day. For various reasons, IT never got around to building a production instance, and so over the last five years, I’ve been maintaining this core piece of Mozilla project infrastructure, which was depended on by TBPL and many, many other tools which interfaced with Bugzilla. People started building things, and then more things, all of which depended on this server for Bugzilla data. We made a dev server VM for it so people could try it out –.
#Bugzilla gmail software#
This software presented a clean, well-documented RESTful interface on the front end, and did all sorts of things on the back end (XML, CSV, RPC, HTML scraping) that developers no longer had to worry about. So around September 2009, I released the first version of my Bugzilla API proxy software, BzAPI. Back in 2009, it was realised by the Foundation that to make everyone happy was (and still is) an impossible task, and I was given a mandate to “help people solve their own problems”.
Then came the browser with all the promises of client side scripting and the developers shouted "I can do anything in a browser using sweet javascript code that you old client/server developers can do in a thick client! It will scale to tens of thousands!!"Ģ years go by as developers embed thousands of lines of sweet javascript code to accomplish what you can do in a thick client in maybe 100 lines (I'm exaggerating here).Complaining about (BMO) is a Mozilla project activity as old as the hills. Companies grew faster than tech services could scale-out servers and management shouted "Oh no! This monolithic application will not scale!" Lets see, first came the client/server applications and all was well! Well, not exactly first, but for the purpose of this discussion I'll say client/server came first.
0 kommentar(er)
