The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht am 26.03.2007 an. Zurück zu allen aktuellen Beiträgen | |||||||||||||||||||||||||||||||||||||||||||
26. März 2007
AMO and the Sandbox
As I mentioned here recently, the Mozilla Add-Ons site ("AMO") is currently being switched to a completely rewritten, new version (v3) nicknamed "Remora". And yes, it had been rolled back after a few hours of operation due to load problems. And it might even go back and forth between versions a few times until Remora is completely up to the task of taking over that high-traffic site. At the time that I'm writing this, the new version is online once again, we'll see if it stays that way or will turn back for more improvements again.
That said, the webdev folks are pretty responsive and fixing lots of bugs that are reported in that new version. For example, the wrong section descriptions I mentioned last time are fixed now. The list of bugs fixed since Remora went live the first time is also worth a read there. Today I discovered though that the "Recommended Add-Ons" listed on the SeaMonkey Add-Ons page are often not compatible with SeaMonkey actually. I guess the fix will also be done fast - filing a clearly described bug is once again the way of choice to get attention to such minor flaws.
The biggest point of discussions around Remora is the Sandbox feature though. Oh, yes, it is a feature, not an easter egg - despite the time of year of its release
The idea of the Sandbox is actually that users can - with lots of warnings - access add-ons that are not yet approved for public use, test them and comment on them and therefore help reviewers with approving new Add-Ons before they go public. There's even a description of the sandbox feature and a policy for public vs. sandboxed add-ons available on the new AMO site. There's still the problem that the sandbox is hard to find (this is being worked on in the "easter egg" bug I linked here) - and the issue that many add-ons that previously were public have suddenly been degraded to the sandbox. Mike Shaver tried to bring some clarity into that: "we chose a threshold to start with to seed the public site". I guess this was a threshold by user comments, ratings and/or download numbers, and that probably works fine for a good number of Firefox add-ons, and they expected all others just get nominated for going public by their authors anyways. Just that the authors weren't directly informed (don't you have all their mail addresses anyways?) before this went public, so they didn't know. And then there are add-ons like dictionaries, which are usually shown on a page that doesn't link comments or ratings and won't get much of those, and which are probably only interesting for smaller local communities (like my Swiss German dictionary) and won't rank high in downloads. Additionally, there are add-ons for less widespread apps (SeaMonkey and Sunbird), which were badly visible before on the old AMO site, and therefore have less comments, ratings, and downloads - and they the download numbers won't ever be nearly as high as those of Firefox-compatible add-ons, just because of the difference in user numbers of Firefox and the other applications.
All that has probably led to widespread sandboxing of certain types of add-ons and confusion among authors, but I'm sure that situation will improve with time and communication.
Additionally, I think that, with the proper "unapproved, testing-only stuff" warnings and with asking people for commenting on the add-on as well as rating it, the sandbox can be made visible much easier - but again, let's see where the "easter egg" bug leads to in this matter.
The SeaMonkey project plans to only link AMO as the source for add-ons (e.g. on our main web page) in the future, first we need to be sure it works reasonably and we have enough available add-ons. My LCARStrek theme somehow already slipped from sandbox to public without me requesting it or me being notified, so we now have the first SeaMonkey theme listed, but I'm sure there are more themes and other add-ons out there. Please, SeaMonkey add-on authors, submit your work to Remora, and ask for it be shown on public pages!
We now have this good system, which is supporting our software well (and will also work fine with the Add-Ons Manager and its auto-update feature in future SeaMonkey versions), so let's use it!
Update (2007-03-27 03:00 CEST):
1) Mike Shaver has restored all pre-existing add-ons to public, only new extension will go through the new sandbox process.
2) Remora seems to stay alive as the new AMO now after some performance fixes.
That said, the webdev folks are pretty responsive and fixing lots of bugs that are reported in that new version. For example, the wrong section descriptions I mentioned last time are fixed now. The list of bugs fixed since Remora went live the first time is also worth a read there. Today I discovered though that the "Recommended Add-Ons" listed on the SeaMonkey Add-Ons page are often not compatible with SeaMonkey actually. I guess the fix will also be done fast - filing a clearly described bug is once again the way of choice to get attention to such minor flaws.
The biggest point of discussions around Remora is the Sandbox feature though. Oh, yes, it is a feature, not an easter egg - despite the time of year of its release
The idea of the Sandbox is actually that users can - with lots of warnings - access add-ons that are not yet approved for public use, test them and comment on them and therefore help reviewers with approving new Add-Ons before they go public. There's even a description of the sandbox feature and a policy for public vs. sandboxed add-ons available on the new AMO site. There's still the problem that the sandbox is hard to find (this is being worked on in the "easter egg" bug I linked here) - and the issue that many add-ons that previously were public have suddenly been degraded to the sandbox. Mike Shaver tried to bring some clarity into that: "we chose a threshold to start with to seed the public site". I guess this was a threshold by user comments, ratings and/or download numbers, and that probably works fine for a good number of Firefox add-ons, and they expected all others just get nominated for going public by their authors anyways. Just that the authors weren't directly informed (don't you have all their mail addresses anyways?) before this went public, so they didn't know. And then there are add-ons like dictionaries, which are usually shown on a page that doesn't link comments or ratings and won't get much of those, and which are probably only interesting for smaller local communities (like my Swiss German dictionary) and won't rank high in downloads. Additionally, there are add-ons for less widespread apps (SeaMonkey and Sunbird), which were badly visible before on the old AMO site, and therefore have less comments, ratings, and downloads - and they the download numbers won't ever be nearly as high as those of Firefox-compatible add-ons, just because of the difference in user numbers of Firefox and the other applications.
All that has probably led to widespread sandboxing of certain types of add-ons and confusion among authors, but I'm sure that situation will improve with time and communication.
Additionally, I think that, with the proper "unapproved, testing-only stuff" warnings and with asking people for commenting on the add-on as well as rating it, the sandbox can be made visible much easier - but again, let's see where the "easter egg" bug leads to in this matter.
The SeaMonkey project plans to only link AMO as the source for add-ons (e.g. on our main web page) in the future, first we need to be sure it works reasonably and we have enough available add-ons. My LCARStrek theme somehow already slipped from sandbox to public without me requesting it or me being notified, so we now have the first SeaMonkey theme listed, but I'm sure there are more themes and other add-ons out there. Please, SeaMonkey add-on authors, submit your work to Remora, and ask for it be shown on public pages!
We now have this good system, which is supporting our software well (and will also work fine with the Add-Ons Manager and its auto-update feature in future SeaMonkey versions), so let's use it!
Update (2007-03-27 03:00 CEST):
1) Mike Shaver has restored all pre-existing add-ons to public, only new extension will go through the new sandbox process.
2) Remora seems to stay alive as the new AMO now after some performance fixes.
Von KaiRo, um 16:05 | Tags: Add-Ons, Mozilla, SeaMonkey | keine Kommentare | TrackBack: 0
Ein Landtagsmandat!
Es gibt Grund zum feiern für mein Alter Ego in PoP - erstmals in Salzburg konnte ich diesmal ein Landatgsmandat erreichen!
Nachdem uns in OÖ die größeren Parteien nicht in der Regierung wollten (dort hatte ich 8 Wochen lang ein Mandat als Landtagsabgeordneter), war ich am 28. Juni 2006 nach Salzburg gewechselt, wo die Kommunikation besser war und die Chancen für eine Regierungsbeteiligung besser gelagert waren. Allerdings gab's dort dann eine längere Durststrecke überhaupt ohne Mandate für unsere Partei (bzw. eine noch längere Zitterpartie, wo's manchmal welche gab, dann wieder nicht) - noch länger allerdings für mich: Als Parteigruppenvorsitzender hab ich zwar seit längerer Zeit unsere wiederkehrenden Regierungsbeteiligungen verhandelt und eingestellt, war aber nie im Landtag vertreten - bis heute.
Jetzt darf ich für die UME endlich auch im Landtag sitzen, hoffentlich bald auch in der Salzburger Regierung
Nachdem uns in OÖ die größeren Parteien nicht in der Regierung wollten (dort hatte ich 8 Wochen lang ein Mandat als Landtagsabgeordneter), war ich am 28. Juni 2006 nach Salzburg gewechselt, wo die Kommunikation besser war und die Chancen für eine Regierungsbeteiligung besser gelagert waren. Allerdings gab's dort dann eine längere Durststrecke überhaupt ohne Mandate für unsere Partei (bzw. eine noch längere Zitterpartie, wo's manchmal welche gab, dann wieder nicht) - noch länger allerdings für mich: Als Parteigruppenvorsitzender hab ich zwar seit längerer Zeit unsere wiederkehrenden Regierungsbeteiligungen verhandelt und eingestellt, war aber nie im Landtag vertreten - bis heute.
Jetzt darf ich für die UME endlich auch im Landtag sitzen, hoffentlich bald auch in der Salzburger Regierung
Von KaiRo, um 02:36 | Tags: PoP | 1 Kommentar | TrackBack: 0
Pingback and TrackBack: ease of implementation (or not)
Finally I managed to implement pingback in addition to TrackBack, and it was interesting to implement both, to compare them from a developer's perspective - as both are technologies that enable other blogs to link back blog entries that link them and this way create a permanent connection between two blogs.
One target of pingback is said to be that it should be "implementable with minimal effort", I also read in a few places that it should not attract spam as easily as TrackBack. The latter has been achieved quite nicely, as the pingback client needs to tell the server the source URL containing the original link as well as its target, and the server needs to verify this link to this target actually exists in the source. TrackBack on the other hand just sends the the URL to link back to and needs no verifications, so strictly according to the spec, a TrackBack server just links back to anything anyone else tells it to link. Of course, most TrackBack servers nowadays do verify that their blog is linked from the source - as does this blog here, like I pointed out in a recent post here.
The ease of implementation was not such a clear win for pingback though in my case. Where it clearly wins over TrackBack is "autodiscovery" (automatically discovering link targets in a blog entry that are able to link back via one of those technologies): While TrackBack uses a rather complicated to detect RDF snippet that needs to be placed in the entry, pingback uses a very easy to read HTTP header (and an also easy to detect HTML <link> tag as a fallback) to detect if some page is pingback-enabled. Telling the other blog that it should link, i.e. actually "pinging" it, is quite simple on the TrackBack side though: do a simple HTTP POST with urlencoded data, get very simple XML as a reply that tells if it was successful or not, and that's it. Pingback on the other hand achieves that part via an XML-RPC call. This might be easy to implement if you have an XML-RPC server running on your site already, but if you don't, it requires you to send a rather deeply structured XML document in a POST request as a client, and as a server, to retrieve the data from that doc (I needed to spend some time to even find out how to get this body of the incoming request in PHP) and send an even more complicated XML reply. So the implementation of the actual ping is (without having working XML-RPC support in place already) much harder for pingback than for TrackBack. I guess there's rarely a technology that has only good sides to it...
BTW, I know that there's some XML-RPC support bundled with PHP (via XMLRPC-EPI), but as there's no good documentation of it anywhere (one case where the else good PHP manual really sucks), I even felt safer to manually deal with that form of communication.
That said, I got both technologies to hopefully work now on this blogging system, including autodiscovery for both of them (if both are supported, pingback is preferred), and I hope users of CBSM and our community system will like them.
One target of pingback is said to be that it should be "implementable with minimal effort", I also read in a few places that it should not attract spam as easily as TrackBack. The latter has been achieved quite nicely, as the pingback client needs to tell the server the source URL containing the original link as well as its target, and the server needs to verify this link to this target actually exists in the source. TrackBack on the other hand just sends the the URL to link back to and needs no verifications, so strictly according to the spec, a TrackBack server just links back to anything anyone else tells it to link. Of course, most TrackBack servers nowadays do verify that their blog is linked from the source - as does this blog here, like I pointed out in a recent post here.
The ease of implementation was not such a clear win for pingback though in my case. Where it clearly wins over TrackBack is "autodiscovery" (automatically discovering link targets in a blog entry that are able to link back via one of those technologies): While TrackBack uses a rather complicated to detect RDF snippet that needs to be placed in the entry, pingback uses a very easy to read HTTP header (and an also easy to detect HTML <link> tag as a fallback) to detect if some page is pingback-enabled. Telling the other blog that it should link, i.e. actually "pinging" it, is quite simple on the TrackBack side though: do a simple HTTP POST with urlencoded data, get very simple XML as a reply that tells if it was successful or not, and that's it. Pingback on the other hand achieves that part via an XML-RPC call. This might be easy to implement if you have an XML-RPC server running on your site already, but if you don't, it requires you to send a rather deeply structured XML document in a POST request as a client, and as a server, to retrieve the data from that doc (I needed to spend some time to even find out how to get this body of the incoming request in PHP) and send an even more complicated XML reply. So the implementation of the actual ping is (without having working XML-RPC support in place already) much harder for pingback than for TrackBack. I guess there's rarely a technology that has only good sides to it...
BTW, I know that there's some XML-RPC support bundled with PHP (via XMLRPC-EPI), but as there's no good documentation of it anywhere (one case where the else good PHP manual really sucks), I even felt safer to manually deal with that form of communication.
That said, I got both technologies to hopefully work now on this blogging system, including autodiscovery for both of them (if both are supported, pingback is preferred), and I hope users of CBSM and our community system will like them.
Von KaiRo, um 01:29 | Tags: blog, CBSM | keine Kommentare | TrackBack: 2
