Posted
over 3 years
ago
by
John Resig
I'm not sure if everyone has been following the recent Microformat work being done at Mozilla, but it's very cool - and exactly what the Microformat movement needs.
I was able to talk with Michael Kaply the night that he released Operator
... [More]
(Mozilla's, sponsored, Microformat extension). This extension is part of the new Mozilla Labs initiative that was just started (It's an attempt to sponsor and promote excellent-quality extensions, and other tools; a terrific idea).
We discussed Microformats in general - and both complained about the shoddy quality of most Microformat parsers. We agreed that in order for the Microformat initiative to move forward, a couple things had to be done:
A standard for parsing Microformats had to be clearly defined.
An excellent implementation of that standard needed to be implemented.
And an important player needed to adopt the use of that tool.
The reason why I'm so excited, right now, is that this is actually happening. In Firefox 3, it's looking likely that there's going to be native handling of Microformats. This would include a defined API for handling Microformats (most likely on the extension level) on any given web page.
This is a huge step forward for the Microformat movement.
Thankfully, Michael has already started developing the solid Microformat Parser, with Andy Mitchell, that will go into Firefox 3. And since this is part of the overall Firefox 3 Content Handling Requirements, it's a big priority for inclusion.
So, what could this content-handling API mean for you, the Firefox extension developer? It means that you would be able to write quick-and-dirty JavaScript to handle matched Microformats - and it'd be blazingly fast.
For example, here's some pseudo-code (any final result will, most likely, be very very different):
Microformats.addHandler("hcard", function(card){
var img = document.createElement("img");
img.src = "hcard.gif";
img.title = card.data.name "'s Personal Information";
card.container.appendChild( img );
});
When it becomes this easy to handle Microformats, it almost becomes harder to not support them in your extensions. I suspect that once this feature hits the big time, we'll see a flood of Microformat-supporting extensions. And this is great for extension developers, the Microformat movement, and, most of all, end users everywhere.
This is a great time to be getting into Microformats. [Less]
Posted
over 3 years
ago
by
marcia
Please visit http://store.mozilla.org/ to see details about our Store Coupon Promotion. This is the first time we are offering this promotion at the Mozilla Store. We have just added a number of new items to the store, including a Firefox...
Posted
over 3 years
ago
Down on the farm all the animals make neat noises, moo, cluck, pfft.
That's where I've been the last two weeks, hacking together a build farm so we can actually get some nightly builds out on a nightly basis (the colors!). I started writing
... [More]
bash scripts but then was introduced to Buildbot. So I've been installing python and twisted and wrestling with cygwin for our windows build boxs. The biggest excitement has been the 2 new Macs we received, a quad g4 to replace the mac mini for ppc builds and a shiny new XServ, quad Xeon 64 bit for the intel builds. It's like Tool Time around here, More POWER!!!
The low down is that the scripts are almost ready and perhaps tomorrow I'll be talking with Rolf and Aus to figure out where to put the packages for download. There may be nightly builds as early as Friday, but probably Monday. Stay tuned! [Less]
Posted
over 3 years
ago
by
mkaply
One of the things I’ve run into with Operator is learning how to parse microformats correctly. Instead of keeping the knowledge I’ve found to myself, I’ve decided to work with Andy Mitchell and create a generic cross browser
... [More]
microformat parser in JavaScript, tentatively called ufParser. That’s the reason I’ve been so quiet.
The parser allows for the creation of definition files for microformats, so that new microformats can be added to the parser easily. So far I have all of the Operator microformats done (hCard, hCalendar, hReview, hResume, geo, xFolk, rel-tag) and I have done XFN.
We’re also investigating the potential to create more generic actions as well (but I’ll maintain compatibility with old style Operator actions).
The next version of Operator will definitely use the new parser, so there might be some regressions here and there. Hopefully we’ll get them solved quickly
Stay tuned. I’m hoping to have something in the next week or so. [Less]
Posted
over 3 years
ago
by
marcia
The QA team is busily testing the Vista fixes that just landed on the trunk, and we can use your help verifying the fixes. Here is how you can help:
(1) Join the #vista channel on IRC (irc.mozilla.org) during the day. Some of the Vista
... [More]
testing team will be in the channel hammering away.
(2) Go to Litmus and run the Windows Vista Test suite. You can find it listed under Firefox.
(3) Go to the Community Test Day Page and run some of the scenarios that are listed on that page. This is the same page we will be using for the Test Day this Friday.
(4) Join our Vista testing list. Send an email ping to marcia@mozilla.org if you are interested in joining this effort.
Remember that we are testing on the trunk first, so the build you want to use is here.
Feel free to post significant comments here. Please check Bugzilla for filing any new bugs. [Less]
Posted
over 3 years
ago
by
gerv
The Firefox trunk has recently acquired a thing called the Effective TLD service, which I have blogged about before. It allows the browser to work out where the registry-controlled portion of a domain name ends and the end-entity-controlled portion
... [More]
begins. For example, in "fred.com", "com" is the responsibility of the registry, and "fred" is the responsibility of the registrant. However, in "fred.valer.hedmark.no", "valer.hedmark.no" is the registry's part. The rules for where to make the split differ between the 250 top-level domains in existence, and so there's no programmatic way of telling. You just need a very big list of all the rules.
Example uses for this data include setting cookies in a safe and privacy-maintaining manner (e.g. no cookies for ".co.uk"), sorting sites by domain in Places, and highlighting the domain name in the URL bar to cut down on spoofing attacks.
Other browsers such as Opera also need this data for the same or similar reasons, so we plan to share it with them. Yngve Pettersen of Opera has come up with several proposed solutions in the past.
Unfortunately Jo Hermans, who has done a lot of the heavy lifting in getting the list off the ground, is currently unable to carry on looking after it due to other commitments. So I'm looking for someone to maintain the list. That would involve:
Set up a small website explaining the purpose of and format of the list
Send an initial email to all 250 registries, telling them about the project and asking for their rules (don't worry, there are mailing lists for this)
Receive update emails from registries and incorporating them into the list
The more accurate the list is, the better a job things like Places will do.
This might be a good job for someone who is reasonably technical, but not to the level where they feel like diving into the Mozilla code. I certainly fitted that description when I started helping out on the project (I did QA), so I'm sure there must be more of you out there. :-)
Please send a link to this blog post to anyone who you think might be interested. [Less]
Posted
over 3 years
ago
by
Axel Hecht
I need to hand in the schedule for the Mozilla Developers Room at FOSDEM in by the end of the week, so I’m making a last call for presentations. If you want to give a talk, please add yourself on the wiki.
Posted
over 3 years
ago
Benjamin recently wrote about the current state of our effort to try to import our CVS repository to... something from this century.
His conclusion is spot on, although I think it... minimizes the head-banging he and I have been going
... [More]
through for a couple of weeks. My original characterization didn't turn out to be far from the truth, it seems... except, it's me and my quad-core-P4-with-4-gigs-of-RAM sitting there, bloodied and bruised on the floor, not ClearCase. ;-)
I was somewhat surprised by the number of responses to Benjamin's post that seemingly amounted to "Can't you just use Subversion? Subversion works. And if you want distributed, use SVK."
Well, the first issue with that is cvs2svn1 doesn't seem to import the Mozilla CVS tree anymore: it's hitting the error that Hg tends to hit2, and while completely dying is arguably more correct, bzr and cvs2svn 1.3.0's approach—annotating and ignoring the error, so the import can actually continue—is much more satisfying.
The second issue is that the march towards a distributed version control system really isn't about a distributed version control system; it's about using a tool that support merging algorithms that weren't invented in the 80s, back when you never did branches anyway, because it was annoyingly difficult with the tools of the time.
During the original discussion, the main issue that limited Subversion's advancement in the race was that it didn't support any better merging functionality or techniques than its predecessor. It requires external tools to record which merges had been performed and the actual algorithms used are the old ones we all love and/or hate.
Now don't get me wrong: I use Subversion for all my personal stuff and I like it. I think it's a great improvement over CVS (which I used for years and imported from) and in many (most?) cases, I would recommend it.
But when you're going to be doing the kind of "agile"3, disruptive, reconstructive work that Mozilla 2.0 requires, at a minimum, you need a tool that makes branching and merging easy. SVN does work for me (and lots of other people and projects) because I'm not faced with, for example, renaming nsIFrame::GetPresContext, a task where a branch makes a lot of sense, and I'm going to be doing hundreds of renames.
I contend that it's not so much that we require (or necessarily even want) a "distributed" version control system. In fact, as a counter example, Perforce is a [closed source] centralized VCS that has a lot of great features, including merging primitives that are awesome. Accurev is another (although, I've never personally used it.)
We just happen to be focused on "distributed" VCSs because those are the only open source offerings that have merging facilities that handle complicated situations and get the merging stuff right. This is likely because a distributed version control system isn't worth anything if you can't merge your work back in easily and [more importantly] reliably.
I'll concede, of course, that once you have things like offline diff/commit and easy patch sharing among peers, all built-in-and-tracked-by the VCS, that's (possibly addictive) icing on the cake.
But it's not about "distributed" part. It's about the capable-merging part.4
Breaking code apart is easy. Putting it back together is hard.
We want and need a tool that intrinsically expects, is designed to handle, and expertly supports the latter.
_____________________
1 As of 1.5.0
2 Which amounts to deleting files which don't exist on branches [possibly yet] that they're being deleted from.
3 I hate using that [buzz] word.
4 Coincidentally, Joel recently blogged about version control systems and large teams, and it seems the Windows team uses a model very similar to that of the 2.6 kernel developers, and possibly similar to what we'll end up using. It seems that easy branching (which is easy) and easy merging (which is hard) is the only real way to scale a development project into the thousands. [Less]
Posted
over 3 years
ago
by
John Resig
In a follow-up to my previous post on DOM Storage, here’s an attempt to answer some of the questions posed in the comments, and elsewhere.
What’s to stop a script from filling an entire storage area with random data?
As best
... [More]
as I can tell with the implementation in Firefox, every time you save data to a storage area, not only is the name of the storage area saved (e.g. “org” or “ejohn.org”) but so is the domain name of the original script. This domain name is what has the 5MB limitation imposed upon it.
This means that a single script could put 2MB of data in globalStorage[’org’] and another 3MB in globalStorage[’ejohn.org’], but attempting to put any more data in will cause an error to occur.
I may be wrong on this point; but if that’s the case, then it will be very hard to stop scripts from filling up “common” areas with nonsense data (and which seems like something that was considered as a fundamental design decision).
(Update: This is, currently, a moot point in Firefox as it does not enable any of the TLD or public storage areas, for fear of an issue like this happening.)
Storing data to globalStorage[’localdomain’]
I forgot to mention that all LAN addresses receive a TLD of ‘localdomain’. For example, if your computer is named ‘anthrax’, you could store data in the following stores: globalStorage[’anthrax.localdomain’], globalStorage[’localdomain’], and globalStorage['’].
This means that you can, in fact, store data “globally” across all pages of an intranet.
What’s with the name “DOM Storage”?
I’ve been having trouble pinpointing this one - but I agree, the name is particularly deceptive. What’s especially confusing is that “DOM Storage” isn’t the official name for this particular feature, “Client-side session and persistent storage” is.
As it happens, Mozilla’s internal name of this features is “DOMStorage” (the names “Storage”, “mozStorage”, and “sessionStorage” were all already in use), I’m beginning to suspect that this naming confusion has stemmed from this, original, feature-naming. (Note: This has been confirmed.)
In reality, the storage area doesn’t really have much to do with the Document Object Model - it really only attaches to the WindowHTML Object. The only time it actually interacts with the DOM, as we know it, is to trigger a “storage” event on the document body.
The storage event
I forgot to mention this in my last post, but this is a rather interesting sub-feature of DOM Storage. Whenever a key/value is changed, added, or removed within a storage area that you have permission to access, a ’storage’ event is triggered, originating from the HTML document body and bubbling its way up.
The only piece of event metadata that is passed along in the event object is the name of the domain that the changed-key is within - and nothing else. (Providing any additional information would serve to be a security risk)
Update: Firefox does currently support this, and you can view a test case here.
Server-side Data
No data from DOM Storage areas is automatically passed to the server. This differs from cookies, which serve as a two-way form of synchronous communication between a server and a browser.
You could work around this limitation with an XMLHttpRequest, POSTing the contents of your relevant storage areas.
Known Bugs
As I mentioned before, Firefox has the only known implementation of DOM Storage available to any browser. However, there are still some serious limitations with it.
sessionStorage - Does not restore data across browser crash/restore.
globalStorage[’org’] - Storing data to a single TLD fails
globalStorage['’] - Storing data to a public area fails
Update: Neil Deakin has gotten back to me and mentioned that the lack of TLD or public storage areas was intentional. When implementing the specification he felt that there was, quite simply, too much of a security risk in leaving those public areas open. I suspect that since Firefox is the first browser to make an attempt an implementation, much of this will trickle back to the specification.
We’re still in the rocky first moments of this feature, but once it starts to pick up some solid adoption (especially amongst other browsers), I suspect that we’ll see the level of quality really start to take off. [Less]
Posted
over 3 years
ago
Rob and I have been dreaming up a new nestmap:
Meanwhile, the birders have suddenly gotten very quiet. This means only two things, they have started coding again, or my new headphones are really awesome.
