Comments on: Good architectural layering, and Bzr 1.1

By: tecosystems » GNOME Do and The Network Backed Plugin Architecture

tecosystems » GNOME Do and The Network Backed Plugin Architecture — Mon, 23 Jun 2008 19:02:02 +0000

[...] Shuttleworth, I think, was right when he said: It seems that one of the key “best practices” that has emerged is the idea of plug-in [...]

By: Bazaar: un CVS distribuito | PettiNix

Bazaar: un CVS distribuito | PettiNix — Fri, 01 Feb 2008 11:18:13 +0000

[...] stesso patron di Ubuntu, Mark Shuttleworth, spinge nell’aumento del suo utilizzo, indicandolo come soluzione del futuro nella gestione dei [...]

By: Ian Skerrett

Ian Skerrett — Fri, 18 Jan 2008 18:42:27 +0000

Mark,

I definitely agree that a well defined plugin architecture helps accelerate the participation in an open source community. We have definitely seen this within the Eclipse community, for instance BzrEclipse. Tim O’Reilly coined the term ‘Architecture of Participation’ and well defined architecture is at the heart of this concept.

By: tecosystems » Do or Do Not Do, There is No OS X

tecosystems » Do or Do Not Do, There is No OS X — Wed, 16 Jan 2008 07:47:10 +0000

[...] “It seems that one of the key ‘best practices’ that has emerged is the idea of plug-in architectures, that allow new developers to contribute an extension, plug-in or add-on to the codebase without having to learn too much about the guts of the project.” Mark Shuttleworth [...]

By: Krenar Qehaja

Krenar Qehaja — Sat, 12 Jan 2008 17:05:45 +0000

@Kevin Menard

this could help Mark if it is on php,

[php]
echo “Copyright © 2006 – ” .date(“Y”). ” Mark Shuttleworth”;
[/php]

By: Bonne conception architecturale en couches et Bzr 1.1

Bonne conception architecturale en couches et Bzr 1.1 — Thu, 10 Jan 2008 13:28:06 +0000

[...] Traduction française de l’article “Good architectural layering, and Bzr 1.1“. [...]

By: tecosystems » links for 2008-01-10

tecosystems » links for 2008-01-10 — Thu, 10 Jan 2008 05:20:26 +0000

[...] Mark Shuttleworth » Blog Archive » Good architectural layering, and Bzr 1.1 “It seems that one of the key “best practices” that has emerged is the idea of plug-in architectures, that allow new developers to contribute an extension, plug-in or add-on to the codebase without having to learn too much about the guts of the projec (tags: markshuttleworth architecture plugins firefox bazaar layers add-on extension) [...]

By: Kevin Menard

Kevin Menard — Thu, 10 Jan 2008 02:33:00 +0000

Mark,

As a side note, you probably want to update the copyright year in your page footer.

By: Robins

Robins — Thu, 10 Jan 2008 01:41:30 +0000

I have been recently been working heavily on a project that i developed both at home and office. Funnily, this meant that two operating systems were used (XP / Gutsy), two databases were used (PostGres, MSSQL) and the icing, two servers were used (FreeBSD / Windows Server 2003).

But only one feedback after it all. Bzr worked flawlessly !

Mark, the way I look at it, different development architectures have their own advantages / disadvantages, but what I believe is far more important are the policy decisions that guide the developers. For e.g. personally I believe bzr’s idea of making renaming a first class citizen is *the most important reason* why I chose bzr for this project even though at that time a similar DVCS (HG) was considered better than bzr 0.92 by a few online reviews.

Put it another way, I believe that in the long run, the thinking behind a project provides a big hint as to whether the project would suit your needs. Then I find in bzr in harmony with my thinking.

By: Kevin Menard

Kevin Menard — Thu, 10 Jan 2008 00:41:37 +0000

I constantly have a love-hate relationship with plugins. They are great because they do lower the barrier to entry for the average developer. As a guy that needs to install them, though, it’s a pain in the neck. On top of that, you do run into the support issue tha Gord mentions. I’ve run into plenty of situations where I rely on plugins X & Y for some product P. X doesn’t get updated for the new version of P’s API, while Y does, and Y won’t backport bug fixes to the old version. So, now I’m stuck with two plugins I rely on that are largely incompatible with one another.

I do think the installation issue is one that requires greater attention, however. It’s the reason that I’ll grab Opera before I grab Firefox or IntelliJ IDEA before Eclipse. When the core is stripped down and you need to grab 10 different plugins to get a reasonable system and there’s no way to easily automate it for all of your work environments or all the work environments of your group, plugins lose their novelty really quickly.

I’d advocate an easy way to install plugins (i.e., have a plugin repository rather than listing them on each individual developer’s site), easy way to duplicate an installation and/or automated deployment, and maybe even wrap up a distribution of the app’s core plus the most popular set of plugins.

For what it’s worth, everytime I go to check out bzr I see that I need plugins to integrate with other version control systems and I’m immediately put off. It’s far simpler to just stay with what I have than it is to play platform compatibility roulette.

Mark Shuttleworth says: I agree wholeheartedly with your observations about plug-in installation, updating, maintenance and version control. Firefox does this best, IMO. It automatically looks for updates, and it assesses compatibility between plug-ins and new versions of the browser.