stream of bytes

Community Wiki gains OpenID support

I’ve just added OpenID support to Community Wiki. It should make it easier for people to edit the wiki, but its also a step in the direction of Mozilla Community Sites package.

I will write a separate post about MCS, but as many of you know since Fx Summit, I’m working on the set of customized open source web apps that will make setting up a community website much easier. One of the webapps that will be offered is MediaWiki, and one of the features of all the tools will be support for OpenID. Using this on Community Wiki is just a first step

Community Wiki

For last two months I have been working on a project that has been in my mind for over 4 years now.

Originally, the idea of what we called a Community Pack appeared during Mozilla Europe Board of Directors discussions between me and Pascal and the first notes drafted by us are located at old MoEu wiki.

Today I’m proud to announce the wiki that one day may become an official community/contribution website for Mozilla. It’s very early in the game, the theme is just something I crafted temporarily, the name has not been decided yet, the structure of the categories may change.

What is there, is an idea with a groundwork already started. The purpose for the website is to help new contributors learn about various activities inside our project and smooth the learning curve.

Beside, the wiki should help people create their own communities, improve community-2-community experience and knowledge exchange. We will try to help smaller communities learn what mature communities know, share the materials we have and address the potential that lies in strong, independent communities existing inside the Mozilla project.

The wiki will not duplicate any material that exists anywhere. It will serve as a kind of roadsign to all the various materials in different places. Wiki.mozilla.org, MDC, SUMO, QMO, SpreadFirefox and others. It’s a Wiki because we want to b

e able to add content in cases where we don’t have where to link to.

The structure of the main page represents the activities that are part of Mozilla, not projects because people who are new to Mozilla don’t know the names of the projects, but will be able to select the activity they’re interested in.

The temporary URL to the front view of the Wiki is http://como.labs.braniecki.net/ but it’ll of course be moved to Mozilla servers pretty soon.

The back end, for editing is http://como-edit.labs.braniecki.net/.

It’s not a perfect solution, but I had no time to work on the skin to make it present all the UI of MediaWiki, especially the theme will be reviewed to m

atch Mozilla sites guidelines.

What now? Well… it’s up to you! First, do you like it? Do you think it may be useful? We want to grow this roadsign, so we want to add urls to your community websites there, to all resources inside Mozilla, and add content in the places where its missing. The one section that requires a lot of work is Community building.

If you are interested in helping, just create an account and start editing! Don’t be afraid of changing thing, we’ll review them.

I will be working on adding content to missing pages, since I’d like all main “category” pages to look at list like Accessibility or Localization. In the next weeks I will be also working on Mozilla customized web tools and Community Website Theme that will help you create new community websites.

TraceMonkey a Tamarin

Wczoraj Mozilla ogłosiła prace nad silnikiem TraceMonkey. TM jest modyfikacją aktualnego silnika Gecko - SpiderMonkey, do którego dodana została opracowana przez pracowników Uniwersytetu Kalifornijskiego implementacja algorytmu JIT. Nie jest to może żadna czarna magia, po prostu opóźnienie wykonywania skryptów JS (każdy kto pracował z JS wie, jakie ograniczenia wydajności JS nakłada - nikt raczej nie pokusiłby się o tworzenie silników graficznych 3D w JS) jako interpretowanych jest tak duża, że okazało się, iż opłaca się skompilować wstępnie kawałki kodu JS i w przypadku występowania powtarzających się procedur odpalać skompilowane fragementy zamiast interpretowania kodu na bieżąco.

Efekty są bardzo wydatne.

Każdy kto śledzi planetę Mozilli widział już wykresy Brendana, Shavera i Schrepa. Ja wykonałem małe testy na benchmarku Dromaeo autorstwa niezrównanego Johna Resiga.

Wykonałem dwa testy - w Fx 3.0.1 i dzisiejszej kompilacji nocnej z włączonym JIT dla treści stron.

Wynik dla Fx 3.0.1, Wynik dla Minefield trunk i wynik porównania dwóch. Przyspieszyć o kolejne 46%? Nieźle… co?

Najlepszą informacją w tym wszystkim jest to, że Brendan twierdzi, że JIT powinien być szybszy w dokładnie każdym teście. Jeśli gdzieś nie jest, jest to błąd i będą to teraz poprawiać… Całość implementacji zajęła 60 dni i jest to wersja bardzo wstępna, najbliższe miesiące powinny przynieść kolejne przyspieszenia wraz z optymalizacją nowych możliwości.

Co z Tamarinem? Tamarin to znacznie bardziej poważny eksperyment, wymagający dużego nakładu pracy. Ma być on podstawą silnika ActionScript, który zastąpi obecny w platformie Mozilla 2 (i w efekcie w Firefoksie 4).

Obecnie prace nad nim trwają w osobnym repozytorium na hg.mozilla.org, i zostanie on włączony do mozilla-central prawdopodobnie po wydaniu Fx3.1. Tamarin ma być oczywiście znowu, znacznie szybszy od TraceMonkey (gdyż będzie korzystał z jego dobrodziejstw i dodawał kolejne), będzie też pierwszą implementacją języka JavaScript 2.0 (który dla mnie jest przede wszystkim pokornym wzięciem największych dobrodziejstw Pythona:) ) ale można go już dziś przetestować kompilując tamarin-central.

Kolcami tej róży są problemy z debuggerami. JIT sprawia, że cały proces interpretacji przestaje być deterministyczny i nie za bardzo wiadomo jak to obejść. Na razie przy włączonym Venkmanie, Gecko wyłącza JIT, ale nie jest to optymalne rozwiązanie i będzie trzeba poczekać, aż Gijs wróci z wakacji i podejmie decyzje co dalej z Venkmanem…

Jeśli ktoś chce włączyć JIT, to może to zrobić na dwóch poziomach - dla stron i dla samego Firefoksa (about:config i szukaj “jit”). Włączenie dla Firefoksa oczywiście znacznie poprawia jego wydajność (duże części Fx napisane są w JS), ale jest w tym momencie dość ryzykowne. Natomiast dla stron jest dość stabilnie (zanotowałem kilka wywaleń w Gmailu i Facebooku tylko) i z każdym dniem będzie lepiej

Docelowo, w ActionMonkey i Mozilla 2, celem Mozilli jest aby jak najwięcej kodu było pisanego w JS, a wydajność JS była porównywalna z kodem kompilowanym (C++)… Coś co wydawało się niemożliwe, nie tylko stało się realne, ale jest aktualnie celem programistów w projekcie Mozilla. Mam nadzieję, że się uda

Mozilla naprawia IE - piekło zamarza?

Ostatnio pojawiły się artykuły na temat kilku projektów wewnątrz Mozilli mających pomóc unowocześnić Internet Explorera, “No browser left behind” Vlada dodający Canvas do IE, czy ScreamingMonkey dający obsługę nowoczesnego JavaScriptu (w założeniu JS2.0) w IE.

Dostałem kilka maili z pytaniami w tej sprawie, parę osób podpytało na Jabberze, a na vortalu DobreProgramy komentatorzy spędzają czas radośnie próbując znaleźć wytłumaczenie dla tego ruchu.

Co ciekawe, wśród tak wielu teorii ukutych na prędce zabrakło tej jednej, rzeczywistej. I wydaje mi się to bardzo symptomatyczne dla współczesnego myślenia, że tego typu wytłumaczenia rzadko przychodzą do głowy.

Wytłumaczenie to brzmi - celem statutowym Mozilli Foundation jest promocja wyboru i innowacji w Internecie.

Takie trudne? My nie walczymy o zajęcie rynku przez naszą przeglądarke. My walczymy o to, aby Internet sie rozwijał i uznaliśmy, że optymalnym sposobem do tego jest stworzenie i promocja przeglądarki, która zagwarantuje rozwój Internetu w modelu opisanym w Manifeście Mozilli (tłum pl w trakcie prac).

Mozilla jest otwartym projektem i działa bardziej jak Bazar, czy środowisko naturalne, niż jak Katedra - zorganizowana i uporządkowana. Wiele rzeczy to inicjatywy oddolne i tak jest w tym przypadku. Ludzie wewnątrz projektu chcą poprawiać świat i jeśli Vlad zauważył, że przeszkodą w adaptacji technologii Canvas jest brak jej wsparcia w IE oraz udało mu się opracować jak to dodać, to jest to idealnie wpisane w model jaki chcemy promować w Internecie.

Tym właśnie, tą różnicą w podejściu, tym, że celem nr.1 każdej firmy są pieniądze, a standardy, otwartość, użytkownicy są środkiem do tego celu, a u nas jest, z definicji fundacji non-profit, odwrotnie wyróżniamy się na rynku i to czyni naszą odpowiedzialność ogromną, a naszą pozycję i nasze możliwości unikalne.

Silme moves to hg.mozilla.org

Just a quick note for all stakeholders: silme has been moved to hg.mozilla.org.

Silme progress

First update after public announcement. During last week, Silme received several minor stability patches in trunk and got initial support (patches [1], requests, feedback on API) from several developers including Stefan Plewako from Aviary.pl and Flock projects, Adrian Kalla from Aviary.pl and an intern in Mozilla Corp., and Pike himself

Beside of that I spent some time during Firefox Summit on talking with people of Pootle/TranslationToolkit fame to identify potential problems that they faced. It was extremely supportive for me and gave my major take away is that if I want to reach my goal of having one, common abstraction layer for l10n objects I have to merge two very different concepts - single locale files (like DTD, properties, ini) and multi-locale files (XLIFF, GetText, tc).

Multilocale branch has been ignited to address this. I already did several tests and it seems that I will be able to support both models in one API without making both feel like hacks.

Pike raised another concern, that I tried to keep for later which is a concept of entity/l10nObject processing. Initially I assumed that it’s a minor topic, and on this level of abstraction I assumed that leaving the entity values unprocessed is OK for now. Unfortunately, especially with L20n being the next Big Thing for Silme, entity processing becomes very important and has to become a legimate element of the library skeleton.

I started early hacks of l20n.py format parser leaving my brain in free conceptual thinking mode and waiting for Pike’s time to talk about grammar inconsistencies.

Last big thing to come is a soon to happen switch from svn repo on my server, to shiny new hg.mozilla.org. This requires me to spend a few hours on svn-to-hg migration tools, but should help with later branching and support easier collaboration between many developers.

Current roadmap is pretty dense for stage3, and may be latter splitted, but does not currently involve work on end-user oriented apps like a webtool. Once I have this two major restructurizations ready (multilocale/pre-processing), I’ll get back to providing proof-of-concept tools. We’re of course looking for more developers so let me know if you’re interested