File:  [mozdev] / helloworld / www / plan.html
Revision 1.14: download - view: text, annotated - select for diffs - revision graph
Tue Dec 9 13:32:29 2008 UTC (11 years ago) by chmille4
Branches: MAIN
CVS tags: HEAD
*** empty log message ***


<h5 class="page-header"><a id="content" name="content">Project Plan - 11/24/08</a></h5>
The project concept is to have a Firefox toolbar button that when clicked downloads the currently displayed page's html source file, all media files, and the html source pages of any linked pages. The files will be downloaded into a user specified directory. The media types that are downloaded in addition to other options will be configurable via a browser accessible preferences GUI.
<br><br>
The Media Collector will have an option to have all pictures (or some subset) stored in Google's Picasa Service or sent to a Facebook album.
<br><br>
The Media Collector will support the following media types:<br>
<t>o	All Browser supported Image Formats<br>
o	Some embedded video (such as youtube video, etc).
<br><br>
<strong>Original Implementation Plan (It has changed since):</strong><br>

The implementation will be broken into two layers: a XUL/Javascript layer and a C++ XPCOM component layer.  <br><br>

The XPCOM component layer will manage file i/o, which includes reading and writing the preferences file and writing the media output files.  The XPCOM component will consist of the following functions: 

<br><br>
readPreferences()<br>
writePreferences()<br>
writeImages()<br>
writePage()<br>
writeLinksFile()<br>
writeVideos()<br><br>

The XUL/Javascript layer will manage all user input, gather all relevant information about the webpage's media, and be the bridge to the XPCOM component.  The Javascript layer will consist of the following functions (preliminary outline that will be added to/changed):
<br><br>
savePreferences()<br>
loadPreferences()<br> 
cancelPreferences()<br>
handleSaveMedia()<br> 	
gatherImages()<br>
gatherLinks()<br> 
savePage()<br> 
saveImages()<br>
saveLinks() <br>
</p>

<hr>

<h5 class="page-header"><a id="content" name="content">Write Up - 12/8/08</a></h5>

<p><b>Mozdev Tools Utilized:</b><br>
<ul><li>CVS - Central code/documentation repository</li>
<li>Mailing List - Developer communication</li>
<li>Web Hosting - Installation/Documentation host</li></ul>

<p><b>Implementation:</b><br>
<b>XPCOM</b> - The c++ component handles saving and reading preferences to and from the filesystem via the mediaDownloader object which has two member functions: DoIt() and SaveSummary().
 The xpcom component links only to frozen libraries through xpcomglue.  This allows a precompiled binary to be placed in the extension/components folder which will autoregister during installation and allow xpcom component functionality by just installing the .xpi!
 Another advantage of using xpcomglue is that the xpcom component can be compiled using the libraries that are downloaded with Firefox opposed to having to build MineFieldDebug from scratch, which can be difficult.<br>
<b>JS</b> - Displays the pref UI, restoring previous settings. Parses the document for requested tags, handles them by type, and calls urlDownloader() on each after processing.</p>

<p><b>Communication:</b><br>
Primary communication was via google's gmail chat, with chat transcripts being mailed to the HelloWorld mozdev mailing list. Non chat communication was via direct email, including mailing list.</p>

<p>For the majority of the project, communication was good with emails and chats occuring at regular if not daily intervals.  As the project deadline
 approached, interaction increased amongst the majority of the members but dropped off with one member.  Ultimately, this lack of correspondence lead to a major 
feature being dropped.  In hindsight better communication during this critical period, would have resulted in a higher quality product and is a lesson I believe
all three of us will take away from this.</p>

<p>Some of the techniques we used would be able to scale with little change, whereas other techniques would have to be completely re-thought. 
The gmail chat would be very difficult to scale as there is no easy way for people to enter into mult-person chats. 
As the size of a group increased, chat would have to be transitioned to IRC.  The mailing list, however, would scale very nicely and relatively few changes 
would have to be made as member size expanded.  Task allocation and managment was handled by dividing the project up at the beginning between the three members. 
This strategey would not scale well and would have to be completely changed for a bigger project.</p>

<p>Overall, this was a very interesting project that forced members to think seriously about the details of how open source works.  
Although not always smooth, the project was an excellent first foray into open source and will encourage  
contribution to open source projects in the future.</p>


FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>