incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <henry.st...@bblfish.net>
Subject Re: On Clerezza trunk, disagreements and modularity
Date Wed, 22 Jun 2011 10:32:00 GMT

On 22 Jun 2011, at 11:39, Bertrand Delacretaz wrote:

> 
> This is a fairly common issue in open/meritocratic/inclusive projects
> like we do at Apache, and the solution is usually to make things more
> modular, in order to reduce the parts where everybody must agree to
> the minimum.
> 
> My usual example is the http server, which is extremely modular: a
> very small core with tons of modules to implement the various
> functions. I think that modularity was initially driven in a large
> part by people being unable to agree on what needs to be part of the
> httpd core.

That is my experience too. Most of my previous open source projects 'failed' because I did
not understand the importance of modularity (sommer.dev.java.net). Or rather they did not
fail, they just forked all over the place, and grew somewhere else into more complex beasts.
I was trying to keep things simple, I realised later I should have made them modular. Still
the code produced there was very small, and there was very little network effect to keep a
common core together.

On the other hand with WebID (foaf+ssl) I stuck to minimal agreement (now to be complemented
with tests) and things also forked all over the place, but all in compatible and complimentary
ways. Ie. dozens of webid implementations in different frameworks that can work together,
and that keep re-inforcing each other.

So with a framework such as this disagreement should be looked at carefully. It usually stems
from tying things together more than they should be, to the benefit of one set of use-cases,
and to the detriment of other. Friction should be seen as a pointer to too tight coupling.

From my point of view there is too tight a coupling now between the User Interface layer and
the DB layer.

All the other issues with ZZ are more of the "it has not yet been built" variety: 
  - no Rule based access control engine
  - silly XML files that need editing by scala code for OSGi (will slow things down for newbies)
  - SPARQL update support? (Tim Berners Lee asked me if ZZ had it, I was not sure)
  - better error reporting (worth looking at playframework: they can point directly to the
source code in their html error reports - can that be done in zz?)
  - ...

Henry



Social Web Architect
http://bblfish.net/


Mime
View raw message