Antti Koivunen wrote:
>
> 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.
Good point.
> 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).
Yes, of course.
> 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.
Yes, but it's a matter of *trust* more than SoC at this point: I give
you the contract, you give me the implementation *and* a way to check
the validation.
As italian, I'm always very sensible at cheating :)
> >>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.
Ok, I'll try to come up with something as soon as I have time.
Ciao
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
