MozillaWiki

Community:SummerOfCode07:Brainstorming: Difference between revisions

Page Discussion

Community:SummerOfCode07:Brainstorming (view source)

Revision as of 17:22, 9 March 2012

1,908 bytes added ,  9 March 2012
no edit summary
(→‎Suggestion List: two suggestions related to the French spelling dictionaries)
No edit summary
 
(12 intermediate revisions by 7 users not shown)
Line 1: Line 1:
<span style="color: red; font-weight: bold">Looking for this year's Summer of Code information? [[SummerOfCode|Step right this way.]]</span>
Projects with a confirmed mentor and approved by the Mozilla project SoC administrator will be moved to [[Community:SummerOfCode07]]. Potential students should look at that page to find project ideas for which we'd like submissions.
Projects with a confirmed mentor and approved by the Mozilla project SoC administrator will be moved to [[Community:SummerOfCode07]]. Potential students should look at that page to find project ideas for which we'd like submissions.


Line 24: Line 26:
| style="background-color: #efefef;" | '''Comments'''
| style="background-color: #efefef;" | '''Comments'''
|-
|-
|-
| valign="top" | Mozilla Encryption and Signing Suite for Stored Communications and Packages
| valign="top" |This project aims to improve the encryption and signing features in SeaMonkey, i.e., the shared Mozilla codebase, with an integrated suite of functions that extend and complete several Mozilla code modules including NSS, PSM, XPInstall, and the Mail and News Backend. These features and improvements will make encryption technologies more feasible and practical, encouraging users to protect the confidentiality of their communications using easy, user-friendly techniques. Many of these features are aimed at improving S/MIME and certificate support and usability in the Mozilla codebase, from the NSS (C language) layer up through the UI layer.
The suite includes solving problems and adding features in:
* the NSS libraries,
* the PSM, and
* the XPInstall UI and backend.
| valign="top" | seantek
| valign="top" |
| valign="top" |The full proposal, including background, was submitted to the Google Summer of Code at 2007/03/18 07:42:04 PDT.
|-
|-
| valign="top" | Internal streamed audio player for Firefox
| valign="top" | Internal streamed audio player for Firefox
Line 71: Line 84:
| valign="top" | HeikkiToivonen
| valign="top" | HeikkiToivonen
| valign="top" |
| valign="top" |
| valign="top" | PGP signature support would probably be easiest to build on top of Enigmail extension. See Metalink which supports associating MD5/SHA1 hashes and PGP signatures with files, and [http://microformats.org/wiki/hash-examples hash microformat] for embedding within a page.<br><br>Making three extra 404 hits on a website for each file downloaded is not a friendly thing to do (remember favicon.ico) - Gerv
| valign="top" | PGP signature support would probably be easiest to build on top of Enigmail extension. See Metalink which supports associating MD5/SHA1 hashes and PGP signatures with files, and [http://microformats.org/wiki/hash-examples hash microformat] for embedding within a page.<br><br>Making three extra 404 hits on a website for each file downloaded is not a friendly thing to do (remember favicon.ico) - Gerv<br><br>Maybe the verification should check the referrer page in memory for additional links which match the given pattern and only download them if a matching link is found (e.g. Apache directory listing) - Felix.Schwarz
|-
|-
| valign="top" | Internal audio
| valign="top" | Internal audio
Line 107: Line 120:
| valign="top" | [[User:piecu|Bartosz Piec]]
| valign="top" | [[User:piecu|Bartosz Piec]]
| valign="top" |  
| valign="top" |  
| valign="top" | Look at Microsoft Outlook or Outlook Express for an example dialog<br><br>What benefits does having such a dialog give us? - Gerv
| valign="top" | Look at Microsoft Outlook or Outlook Express for an example dialog<br><br>What benefits does having such a dialog give us? - Gerv<br><br>If you have a slow connection (ISDN: <8 kB/s) and receive big mails it is nice to have a preview (who sent the mail, how long will it take to download everything etc) - Felix.Schwarz
|-
| valign="top" | Bugzilla: Duplicate Bug Detection
| valign="top" | Implement a system in Bugzilla that detects automatically that the user has likely entered a bug that is a duplicate of another bug, and display a list of bugs that this bug might be a duplicate of.
| valign="top" | [[User:MaxKanatAlexander|mkanat]]
| valign="top" |
| valign="top" | [https://launchpad.net/malone Malone] can do this now, although  I'm not certain its code is actually open source. (Anyhow, GPL'ed code can't be included in Bugzilla, which uses the MPL.)
|-
|-
| valign="top" | "Search as you Type in addressbar" extension
| valign="top" | "Search as you Type in addressbar" extension
Line 146: Line 153:
Thank you jigar, I didnt know about the browsersync.  
Thank you jigar, I didnt know about the browsersync.  
<br>
<br>
(To Gerv):For the storage backend i was thinking about implementing it via XML files. What is your opinion for a backend storage ? Thank you
(To Gerv):For the storage backend i was thinking about implementing it via XML files. What is your opinion for a backend storage ? Thank you<br><br>I think you can't sprinkle magic XML pixie dust on a hard problem to make it easier. Why are the files not stored server side in whatever format they are stored in the profile? - Gerv
|-
<br/>
| valign="top" | SVG as an image format
(To Gerv): lol pixie dust.<br/>
| valign="top" | One of the possibilities that having a native SVG implementation in the browser provides is being able to use SVG in contexts where normally a raster image would be used, such as &lt;html:img&gt; and CSS properties that accept images.
I was thinking of having the plugin record all the information and put it into an xml file then encrypt and send to the server. When fetching the xml from the server the plugin would grab the xml deycrypt and then do the dirty work.
 
Someone interested in taking this on as a SoC project would need to be pretty familiar with the Mozilla codebase, as this involves getting bits of code that weren't originally planned to work with one another to play nicely together.
| valign="top" | tor
| valign="top" | tor
| valign="top" |


The reason for xml is because the only thing i need to load are bookmarks, history, links to plugins and browser settings. All of this is plain text that each plugin could reconize. So something light and fast to transfer no matter what connection speed your on.
|-
|-
| valign="top" | Merge the two existing French spelling dictionaries
| valign="top" | Index visited pages. Allow query on it.
| valign="top" | There are currently [https://addons.mozilla.org/thunderbird/dictionaries/?lang=fr two French spelling dictionaries] for MySpell. The first was made available from a former ISpell dictionary, and it was later "enhanced" by another group wanting to support new spellings only (1990 reform), although those are not mandatory. As a result, we have two dictionaries, but none of practical use (the first is outdated, the other is underlining perfectly valid words).
| valign="top" | People need to re-find the information that they have already found on the web. This mechanism is currently provided through bookmarks, history and the navigation buttons. Firefox 3 is set to include a number of features through “Places”. “Places” can be further enhanced by allowing user “word-search” the visited web pages. This project will add indexing capabilities to firefox and allow user queries on visited web pages. Thus helping the user find what they need to know. Reported as an enhancement for firefox3. {{bug|342913}}
 
| valign="top" | [http://wiki.mozilla.org/User:Mindboggler Kunal]
A possible implementation of this project would be to take the new dictionary, re-add the hundreds of words that were removed from the old one, and enhance it in other ways (for example, HunSpell allows you to remove some words from the spelling suggestions without underlining them). It might looks like a trivial task, but it is not the case. There were structural changes in the affix dictionary file which can't be resolved by a simple diff.  
| valign="top" | Looking for mentor
| valign="top" | Benoit / [http://frenchmozilla.sourceforge.net/ The FrenchMozilla team]
| valign="top" |Places will add exciting capabilities to firefox. Indexing visited pages is a consistent demand seen in the wikis. Further users spend a lot of time on re-finding information on the web. A feature like this will enhance his user-experience. Sooner or later, competiting browsers will implement this feature. An early start on this will make firefox even more competitive compared to its rival browsers.
| valign="top" |  
| valign="top" |
 
|-
|-
| valign="top" | Create a new French dictionary (HunSpell) from scratch
| valign = "top" | CRON-like repeatable event specification in Sunbird
| valign="top" | No matter how good the French spelling dictionary may become, it can't be shipped with Firefox or Thunderbird because of licensing issues (It's GPL only, Mozilla products are tri-licensed)[http://frenchmozilla.sourceforge.net/blog/index.php/2006/02/02/21-correction-orthographique-et-logiciels-mozilla explanation in French].
| valign = "top" | Desktop calendar applications use repeatable event specification where a user can '''exclusively''' choose one of the following repeat patterns: daily, weekly, monthly, yearly. Server-side deamon CRON uses more sophisticated way of repeat pattern specification. One can mix daily patterns with weekly patterns and etc. in one event specification.
This proposal is to build a new French dictionary from scratch, taking advantage of the new features in [http://sourceforge.net/docman/display_doc.php?docid=29374&group_id=143754 HunSpell]


Someone interested in taking this on as a SoC project would probably need to have a strong background in linguistics or a similar field.
The project's aim is to implement CRON-like pattern specification in Desktop calendar application Sunbird. The idea is new and not seen in any other calendaring application due to the following reason. CRON uses on-line algorithm: checks every minute if current time/date matches any of the list of patterns. Desktop calendar however, needs daily, weekly, monthly (and sometimes yearly) view. Generating all occurrences of a pattern within a specified time bound is not an easy task. I have been doing research in this topic and came up with an idea of doing this kind of computation efficiently. I managed to implement it in a commercial system that is not a calendaring application but has similar functional requirements. I have put algorithmic design into a [http://www.genijusz.org/zalewski07calendar.pdf whitepaper] that explains all the details.
| valign="top" | Benoit / [http://frenchmozilla.sourceforge.net/ The FrenchMozilla team]
| valign="top" |
| valign="top" |


Now I would like to implement this algorithm in an open source calendaring application as a proof of concept of my algorithm.
| valign = "top" | [http://wiki.mozilla.org/User:Dominikz Dominik Zalewski]
| valign = "top" | Looking for mentor
| valign = "top" |
|}
|}
Gerv
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/52870...405873"