On Tuesday, Sep 23, 2003, at 14:46 Europe/Rome, Bertrand Delacretaz wrote:
Le Mardi, 23 sep 2003, à 14:33 Europe/Zurich, Nicola Ken Barozzi a écrit :
Bertrand Delacretaz wrote:
Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a écrit :...And maybe also use a low-tech way of adding a WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the block source dir to make it clear to CVS browsers and coders of the status of the code.Or rather an XML block description file?
The upcoming block descriptor could include meta-information relating to the block's "stamping" status.
The problem I see with having only a descriptor is that one hat to open the file to see the status, and few will do, as the current situation shows.
That's why a file with a descriptive name can initially alert users better...
Why not, I see your point.
But I also think blocks "quality descriptors" need to move beyond just "marked alpha", to more precise descriptions of how mature/usable/certified a block is.
This info should also be used by the block deployer for warnings when installing non-certified, alpha or unstable blocks.
Say we had a rating system like this:
1) Development status: a) design b) under operation c) maintainance
2) API status: a) unstable b) stable
3) Community level: a) open individual effort b) open plural effort from same affiliation c) open diverse community d) closed effort
Now, for example, you want to deploy
http://mycompany.com/blocks/myblock/1.0
in your system. This block depends on the block behavior
http://apache.org/cocoon/block/pdf/1.2
so, after you have deployed your block, the block deployer will ask the block librarian:
Request: who implements http://apache.org/cocoon/block/pdf/1.2?
Response: a) http://apache.org/cocoon/block/FOP/2.3.343 implements http://apache.org/cocoon/block/pdf/1.4 has rating [1c,2b,3c]
b) http://apache.org/cocoon/block/FOP/3.0.24 implements http://apache.org/cocoon/block/pdf/1.12 has rating [1b,2b,3a]
c) http://apache.org/cocoon/block/iText/1.0.3 implements http://apache.org/cocoon/block/pdf/1.3 has rating [1c,2b,3b]
and prompts the user for a choice.
- o -
The system I outlined above seems really nice, but, IMO, has a few serious drawbacks:
1) it requires a central authorithy of certification 2) it creates an incredible amount of friction
If we use http: block-id URI, the block librarian will, probably, be connected to the URI used as a URL to localize a service that provides:
1) description of what that behavior does 2) list of available implementations of that behavior
This means that if the behavior is http://mycompany.com/block/whatever/1.0, we don't have control (nor should!) on what they say. It is entirely possible that they pretend that they have blocks which are developped by a diverse community when they do not.... and, if questioned, they would simply say that "diverse community" doesn't have an objective meaning and they used their own.
But such quality metering would disturb even here: there are situations (even today on our current blocks!) where the "diversity" of the community around a single block is not so easy to measure and might very well be considered "marketing" by some people that are investing in the blocks... thus creating friction between blocks that perform similar implementations.
- o -
I propose a much simpler scheme. A block can be:
1) certified 2) not certified
A certified block is said to be guaranteed by the certifier (not only the Apache Cocoon project, but any organization willing to certify their blocks) that this block is usable in production and will be maintained in the future.
In short, it's safe.
NOTE: this certification process does *NOT* imply that not-certified blocks are unsafe and might contain viral code or spyware. not at all. the block deployment mechanism will do a signature verification with the block librarian even for uncertified blocks. certification is meant to guarantee the "backup" of a community or company behind the block.
So, the new librarian response would be
Request: who implements http://apache.org/cocoon/block/pdf/1.2?
Response: a) http://apache.org/cocoon/block/FOP/2.3.343 implements http://apache.org/cocoon/block/pdf/1.4 certified by: Apache Cocoon
b) http://apache.org/cocoon/block/FOP/3.0.24 implements http://apache.org/cocoon/block/pdf/1.12
c) http://apache.org/cocoon/block/iText/1.0.3 implements http://apache.org/cocoon/block/pdf/1.3 certified by: Apache Cocoon
NOTE: if a block is not maintained anymore, the librarian should not list it up front.
This allows other entities to do certification (and this would mean that *they* provide support and community/company backup of future development) [if they lie, well, users will know and news will spread], but, more important, it will require a single 'all encompassing' vote from the community which would be: "are we ready to support this from now on?"
Which, IMO, is a much easier question to ask than a myriad of small non-objective questions like the above.
Thoughts?
-- Stefano.
