Stefano Mazzocchi wrote:
> Antti Koivunen wrote:
>
>>Stefano Mazzocchi wrote:
>>>
>>>1) no description: blocks identify their contract with an URI that
>>>that's it, there is no way to validate the fact that a block implements
>>>a specified contract, this is the weakest form of contract. It's easier
>>>to implement and places the burden of validation at runtime.
>>
>>Probably not enough, but must be possible, i.e. the block manager must
>>provide a way to turn off validation for certain blocks.
>
>
> Hmmm, ... but shouldn't we force block compliance automatically? just
> like you can't turn off interface checking when you compile your java
> code?
Well, this is a bit different. It might be quite convenient during
development, e.g. the deployment is faster and it's possible to
add/remove features without having to update the descriptor every time.
Also, if the URI is used to locate the descriptor, there's always the
possibility that you're offline or behind a firewall (although the block
manager should provide a way around this by giving the option of storing
the descriptor locally).
Of course, I agree that strong compliance checking is a good idea. My
point here was convenience in certain situations. Possible modes of
operation could include:
1. Validate everything. Only the resources explicitly defined in the
descriptor are available.
2. Check dependencies but allow the block to be queried for resources
not explicitly defined in the descriptor.
3. Only check the URI. All other validation occurs at runtime.
>>>2) little description: the contract identifier indicates the 'skeleton'
>>>of the contract but doesn't declare more detailed behavior. There is a
>>>way to perform structure validation on the blocks and also a way to
>>>auto-document the block contract itself, but the behavioral validation
>>>cannot be automated and it's left to the user checking at runtime.
>>
>>I think we should provide this, at least, e.g. the following would
>>actually go a long way:
>>
>> <provides-file name="xslt/document2html.xslt"/>
>> <provides-implementation interface="com.mystuff.MyThing"/>
>
>
> Yes, this is where I aim to start.
Very good.
>>>3) detailed description: the contract identifier indicates both the
>>>skeleton and the behavior of the contract. This allows high granular
>>>automatic validation.
>>
>>Sounds good, but would be difficult to implement using just an XML
>>descriptor.
>
>
> If you are saying that the XML descriptor might get insanely complex, I
> totally agree.
Exactly my point, but as said before, a few simple validation rules
would go a long way (but probably not all the way).
>>Following proper SoC, perhaps the role itself should provide
>>the tools for more complex validation.
>
>
> No, this *breaks* SoC! Validation is not your concern is *our* to
> understand if what you provided us with works depending on the contract
> that we are expecting!
Well, SoC isn't just about who writes the Java code. Offering a clean
Java API to the block (role) authors for defining the validation rules
might be better than offering an "insanely complex" XML API. Our main
concern is to perform the validation in a uniform way according to these
rules.
>>The role descriptor could make
>>use of the simple built-in validators (see above) and/or define custom
>>ones if necessary.
>>
>>It should be possible to define an 'intermediate' API to make it easy to
>>implement new validators, e.g.
>>
>> interface Validator
>> {
>> void validate( ValidationContext ctx ) throws ValidationException;
>> }
>>
>> interface ValidationContext
>> {
>> BlockInfo getBlockInfo();
>> URL getResource( String name );
>> ClassLoader getContextClassLoader();
>> Configuration getConfiguration(); // from the role descriptor
>> }
>>
>>This approach would allow practically any level complexity, but would
>>also mean that the role might not consist of just the XML descriptor,
>>i.e. we might end up with another archive format, say '.cor'. Still,
>>it's probably be better than trying to please everybody and ending up
>>with 50kB role descriptors.
>
>
> Hmmm, no, I was thinking more of using namespaces to trigger different
> validation behavior during installation.
I'm also quite hesitant to go beyond XML, but it might be difficult to
define standalone roles. Consider the following fairly simple example:
<validate-xml file="foo.xml" schema="http://mystuff.com/xfoo"/>
Now, if the schema URI does not resolve to a valid schema (or there's no
internet access or the server is down), we have a problem. There are a
couple of possible solutions (pre-install the schema, require momentary
internet access), but wouldn't it be more convenient to download a
single file that contains everything? Then we could do something like:
<validate-xml file="block:foo.xml" schema="role:schema/xfoo.xsd"/>
This is just one example, but I'm pretty sure there other similar
situations.
(: A ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
