Release 0.1 Finished !

So Today, i finally finished the "Release 0.1" of my project which was as following

Release 0.1

Goals: Document the following Storage API Interfaces

• mozIStorageService
• mozIStorageConnection
• mozIStorageStatement
• mozIStorageValueArray
• mozIStorageProgressHandler

Basically, the first thing that was needed to be done was to start reading about the Storage API documentation that already existed on the MDC website. It was a pretty interesting read, because it made me understand how the actual Storage API system works and how each interface and their function works together to create this secure and efficient structure of bundled interfaces that makes up the Storage API.

After which, i started reading into the Storage API IDL files that contain information about set of interfaces that lets extensions store data in a local database. Now in my opinion, the IDL files are very helpful for understanding the structure and functionality of related set of interfaces. It shows you the available methods, attributes, constants and lots of other dependency attributes that makes up an interface. The impressive thing is that each method, attribute and constant have comments associated with them, so it is really easy to understand what is going on inside the interface and how each attribute and method is working together or with other interfaces to complete their given task. Not only that, most of the time, there existed a general comment about the functionality of main interface itself, so even before reading into the methods and attributes comments, the main general comment information gives you detailed knowledge about functionality of interface at large.

After i was done reading about the IDL files, i started documenting the Interface Reference Documents and to my surprise, the process is very similar to documenting a wiki page. Most of the syntax was similar to wiki syntax like URL binding and formatting. The good things about this documentation styles include how easy and user friendly the documenting part is, it bends to user needs and makes it very easy to input redundant information without scratching your head or doing any excess work.

At first, i just started documenting the IDL interfaces into the respective MDC - Interfaces Documentation section. But i wasn't following any set of rules, because i just looked at some existing examples of interface documents on the MDC website and i tried to mimic their style of documentation structure. It took me at least a 24 hours+ to get all 5 interfaces documented and after i was done, i found out that the way i documented them doesn't meet the documentation standards of the MDC documentation rules. Which was a waste of time and then Eric Shepherd guided me into the right direction of applying standardization process for my documents.

So basically i rehashed everything into the new standard style of documentation and the work was done in couple of more hours. It was a really great process of carrying out documentation for such important API's but at same time, i was bit disappointed in some area's, especially when certain users would edit your document without any given feedback and just change it to their own style without telling you what did you do wrong? So i ended uo scratching my head couple of times and wondering why some unknown person is editing my Article file? But after talking with them about the matter, it ended up being personal preference of following standards. There are many ways to document at MDC website but there is only one effective way of doing it, so this was the lesson i learned in this Release 0.1 of my project.

Also, much of my Thanks goes to Eric Shepherd for helping me out during the harder part of documentation and always correcting my mistakes as i moved forward with the documenting. If it wasn't for him, this documentation project could have ended up being a big disaster but Eric helped me out on many difficult steps and guided me into the right direction of documentation. Thanks Eric! Also i have to say that the open source community for documentation is really awesome and generous, i didn't feel any pressure from anyone on my documentation process. Especially, if i did something wrong, i wasn't corrected harshly on my mistakes but i was rather encouraged and guided to do things in an alternative manner without any harsh critique or pressure. It makes you feel that you belong to a great community rather than making you feel like an outsider.

I would love to hear feedback about my work and if someone has any comments or critique, feel free to leave a comment here. The interfaces links are parsed on the top of this article. Thanks for reading and good luck with your project.

Bugzilla experience

Watching someone on BUGZILLA is really a weird experience. Not only did my Seneca learn account almost got shut down because of mass of email, i was constantly going back and forth reading about bugs email and trying to understand what is going on. And half the time i had no idea what was going on, it was a really crazy experience.

The person i added in my watch was "Ted" (:luser) and i got tons of email everyday from "bugzilla-daemon@mozilla.org" about commenting and duplicate fixes, but half the time i didn't know which bug they were talking about. The interfaces of BUGZILLA is very buggy and it isn't very effective at information passing. I seriously gave up after couple of tries to decode what was going on. I hope that they can make better interface and structure of dealing with bugs in BUGZILLA or maybe i just didn't get it and have to spend more time in order to grasp the things in BUGZILLA environment.

Does anyone else thinks its effective and not buggy or is it only me that is getting hard time understanding this thing?

Firefox modified!

Finally, i got it working. It took a little while but now with the correct build and the correct findings for the code change, the Firefox build with edited "tabBrowser.xml", the new tab opens between tabs rather than in the end !

It was quite an entertaining and informative experience!

Here is the edited code : tabBrowser.xml
------------------------------------------------------------------------------------------------
RCS file: /cvsroot/mozilla/browser/base/content/tabbrowser.xml,v
retrieving revision 1.243
diff -u -8 -p -r1.243 tabbrowser.xml
--- tabbrowser.xml 18 Sep 2007 00:59:41 -0000 1.243
+++ tabbrowser.xml 16 Oct 2007 22:11:17 -0000
@@ -1088,17 +1088,17 @@
if (!bgLoad) {
function selectNewForegroundTab(browser, tab) {
browser.selectedTab = tab;
}
setTimeout(selectNewForegroundTab, 0, getBrowser(), tab);
}
if (!bgLoad)
this.selectedTab = tab;
-
+ var position = currentTabIndex + 1;
return tab;
]]>

@@ -1173,17 +1173,18 @@
t.maxWidth = this.mTabContainer.mTabMaxWidth;
t.minWidth = this.mTabContainer.mTabMinWidth;
t.width = 0;
t.setAttribute("flex", "100");
t.setAttribute("validate", "never");
t.setAttribute("onerror", "this.parentNode.parentNode.parentNode.parentNode.addToMissedIconCache(this.getAttribute('image')); this.removeAttribute('image');");
t.className = "tabbrowser-tab";

- this.mTabContainer.appendChild(t);
+ var currentTabIndex = this.mTabContainer.selectedIndex;
+ this.mTabContainer.insertBefore(t, this.mTabContainer.childNodes.item(currentTabIndex + 1));

if (document.defaultView
.getComputedStyle(this.mTabContainer, "")
.direction == "rtl") {
/* In RTL UI, the tab is visually added to the left side of the
* tabstrip. This means the tabstip has to be scrolled back in
* order to make sure the same set of tabs is visible before and
* after the new tab is added */
@@ -1952,17 +1953,17 @@
this.mTabListeners.splice(aIndex, 0, this.mTabListeners.splice(aTab._tPos, 1)[0]);

var oldPosition = aTab._tPos;

aIndex = aIndex <>
this.mCurrentTab._selected = false;
// use .item() instead of [] because dragging to the end of the strip goes out of
// bounds: .item() returns null (so it acts like appendChild), but [] throws
- this.mTabContainer.insertBefore(aTab, this.mTabContainer.childNodes.item(aIndex));
+ this.mTabContainer. Before(aTab, this.mTabContainer.childNodes.item(aIndex));
// invalidate cache, because mTabContainer is about to change
this._browsers = null;

var i;
for (i = 0; i <>
this.mTabContainer.childNodes[i]._tPos = i;
this.mTabContainer.childNodes[i]._selected = false;
}
------------------------------------------------------------------------------------------------

Modifying the Firefox browser

Finally, i got time to give it a try and edit the browser and make the new tab feature work but even before getting to that point, i ran into tons of problems. I found out on the LXR and MXR which place to edit the code to get the new tab feature to work but then i inserted the code into my ff-build that i had build previously and it failed.

After a lot of debugging, the problem seems to be in my initial build rather than anything else, thats why i won't compile because when i checked it out, it was on fire and i thought those were some normal warning only but now i have to go back and make new build and now its done and it's time to implement the browser modification, hope it works this time!

Working on Release 0.1

Finally got time to start working on my open source project this weekend. I started reading into the Storage API Documentation. That was actually a great insight about the Firefox (v2)'s database storage system.

Before i started reading about the Storage API database system of Firefox, i thought that it might talk about the WHATWG DOM storage feature of Firefox 2 but to my surprise, the Storage API is completely different thing, because Storage API is for extension authors and Firefox components only.

Now after reading all about this, i am ready to work on the (IDL - Interface Definition Files) and transcribing that information into "Interface Reference Documents Format". Seems like a long task but a very interesting one indeed.