Release 0.3 finished!

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

Release 0.3

Goals: Document the following Storage API Interfaces

• mozIStorageDataSet
• mozIStorageStatementParams
• mozIStorageStatementRow
• mozIStorageStatementWrapper
• nsICache
• nsICacheEntryDescriptor
• nsICacheMetaDataVisitor
• nsICacheListener
• nsICacheService
• nsICacheSession
• nsICacheVisitor
• nsICacheDeviceInfo
• nsICacheEntryInfo
• nsICachingChannel
• nsIAccessible
• nsIAccessibleDocument
• nsIAccessibleEditableText

So for the 0.3 release, i had to do around 20 interfaces documentation and i ended up documenting 17 of them because two of them were "not found", i have a feeling that the developers changed the interfaces dependency or dissolved those two particular interfaces (nsIAccessibleAction, nsIAccessibleCaret) all together, and the last one of them (nsIAccessibilityService) didn't have any interface comments and after talking to "Aaronl" on Chatzilla about the Accessibility interface, he told me that this particular interface is going to take long time to document, because you have to understand each and every method responsibility along with interface purpose in order to document it and we didn't have enough time to go over all this since the release date was tonight. Hence i missed out on documenting one good interface that i was really looking forward to.

Other than that, the routine for documenting other interfaces was pretty much the same where i had to go and read about the interfaces general information first, like Storage API, Accessibility interface documentation that already existed on the MDC website. Since i have done some of the Storage API documentation before, it was easy for me to document them. One of the interfaces in Storage API didn't have enough information (mozIStorageStatementWrapper) hence i just jumped into the "Chatzilla" (#developer) channel and asked "Vladimir Vukicevic" (vlad) for help and he gave me enough insight about the interface that rest was really easy to document.

After which i did some of the Cache interfaces documentation, there seems to exist no external documentation for them on the MDC website, hence i just winged it by reading the interfaces and following the comments flow! Next, i started reading into the Accessibility IDL's and surprisingly they had no documentation at all, at least some of them and it made it very difficult to follow. The first two were easy but the last one "nsIAccessibilityService" was the hardest one to document and it took the most time and i was still not able to complete it, which was a disappointment for myself.

Another thing that i really found helpful doing this time was joining the "dev-accessibility-request@lists.mozilla.org" mailing list and asking the people there for help in regards to the Accessibility interface documentation. In the start, i joined the wrong mailing list and someone directed me to the correct mailing list where i would find the Accessibility interface related information. Thanks goes to "Alexander Surkov".

Again much of the thanks goes to "Eric Shepherd" for guiding me and helping me with all the proper documentation. Cleaning up any mess that i left behind in documenting some interfaces and also for being supportive every time i needed help and felt lost. Also it was nice to see "Kenneth Lee" and "Andrew Fung" learning so fast about the MDC interface documentation style. I wish both of them good luck on their projects.

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.

XPCOM Chrome Lab!

So this was basically the our last lab for this class. The lab was in regards to "Adding Chrome to FirstXpcom Lab".

The lab is pretty basic and very simple to follow. In fact, this was first lab that didn't give me much trouble and just gave me the results as i needed. It's either the easiness of the lab or the fact that wiki notes were very well written and you just had to follow them through.

The following steps were to be followed in order to complete the chrome lab:

(1) Create the extension through the online wizard located at: http://ted.mielczarek.org/code/mozilla/extensionwiz/

(2) After which find the name of your profile by using the following command "cat profiles.ini"

(3) Make sure when you echo the firstxpcomchrome, it should read "firstxpcomchrome@senecac.on.ca"

(4) In the end, i finally went to “Tools” section which contained a red text (kind of like a link) and then i clicked on it which generated a pop-up input box, i entered a value in it and voila, the result is in the snapshot below!

XPCOM Lab!

The XPCOM lab was rather difficult for me to finish with all the other assignments due and the open source release 0.2 due the same week. But today's lab time really helped me in finally completing the lab. I talked to Arman and he guided me in the right direction of how to finish the lab and what i was doing wrong and now it's finally done.

One thing that was neat to know after reading and doing this lab about XPCOM was how components have ability to implement multiple interfaces. Something i never thought about before.

The error i was receiving was something like this : "Malformed File: Minefield could not install this item because "insall.rdf" (provided by the item) is not well-formed or does not exist. Please contact the author about this problem"

And then Arman showed me his blog and that resolved that issue and rest was easy. Glad to have made my first XPCOM component!

Release 0.2 finished!

I finally finished the "Release 0.2" of my project which was as following

Release 0.2

Goals: Document the following Places API Interfaces

• nsIAnnotationService
• nsIBrowserHistory
• nsIDynamicContainer
• nsIFaviconService
• nsILivemarkService
• nsINavBookmarksService
• nsINavHistoryService
• nsITaggingService
• nsIAnnotationObserver
• nsINavBookmarkObserver
• nsINavHistoryQuery
• nsINavHistoryQueryOptions

Just like before, basically, the first thing that i had to do was to start reading about the Places API documentation that already existed on the MDC website. Places API was a very interesting read because it is future implementation rather than already existing feature in Firefox. The Places API is mainly a re-write of Firefox's bookmarks and history system. It aims to have significantly more flexibility and the ability to have complex querying. It also includes some new features such as favicon storage, and the ability to annotate pages with arbitrary information. It also includes a lot of new UI.

After reading all this documentation, i read the IDL's and basically just documented them to the MDC Documentation website. I learned some new syntax into documenting some of this stuff, like how to make headers for FIREFOX 3 version, how to insert WARNINGS with standard format and how some IDL interfaces includes definition and declaration of more than one interface and that was really interesting to see how some "observers" were documented and inserted into same IDL files.

Again, much of my Thanks goes to Eric Shepherd for helping me out with all little tweaks that needed to be done and formatting my documents the correct way and guiding me along the way into how to document more effectively.

For "Release 0.1", i documented 6 IDL files but for my "Release 0.2", i ended up documenting 12 interfaces. Which tells me that i have grasped the idea of how to document these IDL's and i feel like i am getting better at it with every release.

Note: I have noticed that a lot of students when they were told to look for Interfaces documentation, they went into "mxr" and "lxr" to search for the IDL's, but i would like to inform them that it is better if they went to the MDC website instead and looked over the interface documentation there rather then on "mxr" and "lxr" because this is exactly why the MDC website exists, to guide you to proper documentation on these things. So please, use MDC website as much as you can, it is a great domain for extensive knowledge in regards to Mozilla applications. Thanks!

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.

Patching Thunderbird!

This week lab involved patching Thunderbird application for a bug. The bug did the following actions:

If u write some text in this format in new compose message in the Thunderbird application:

Does Wednesday aft. work for you?
I'll tentatively schedule for 3:30 on Wednesday.
We'll come to S@Y...where should we meet?

It will be displayed in the following manner at the receiver's end of the email in Thunderbird:

Does Wednesday aft. work for you?
I'll tentatively schedule 3:30 on Wednesday.
We'll come to S@Y...where should we meet?

So basically, what Thunderbird application is doing is that it automatically converts any text after the "@" sign followed by a "." into "Mailto:" link.

Solving this problem wasn't hard because David already pointed us out where to find the bug so we just edited the file, found the instance where "@" checks are done and change it, so that the application works without breaking and changing upper displayed text into "Mailto:" link.

Interesting lab. I was kind of thrilled with my results in the end, even though its a very simple way of completing the lab.

The patch can be found here:
http://zenit.senecac.on.ca/wiki/index.php/User:Arehman4

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?