cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [design] Cocoon Blocks 1.1
Date Sun, 03 Nov 2002 22:22:15 GMT

With this syntax how would you say that compatibility is guaranteed
from version 1.1.0 through 1.3.5 ?


Isn't the standard Java versioning mechanism for JARs good enough?
It has 2 separate versioning conepts: Specification Version and
Implementation version.

http://java.sun.com/j2se/1.4/docs/guide/versioning/spec/VersioningSpecificat
ion.html#PackageVersioning



Ivelin



----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Sunday, November 03, 2002 7:56 AM
Subject: Re: [design] Cocoon Blocks 1.1


> Sylvain Wallez wrote:
>
> > The contract of a block should be services identified by their URI,
> > and not files at well-known locations (even if these 'files' are in
> > fact produced by a pipeline).
> >
> > <snip/>
> >
> > By considering blocks as pipeline services, we really achieve true
> > polymorphism for blocks, because we totally abstract the way their
> > contracts are implemented.
> >
> > [note that all the above isn't in fact block-specific and can be made
> > today inside a single sitemap]
> >
> Gotcha!
>
> What can I say: I agree!
>
> >
> >
> > After this we had a long conversation about the semantics to be used
> > to identify which part of a pipeline we want the caller to use, which
> > unfortunately fell flat because I wasn't able to make you understand
> > my thoughts. I'd like someday to have the luck Carsten had recently to
> > meet you for real. Too bad the GetTogether is the same week as the
> > ApacheCon :-(
>
> Yeah :/ well, you know, you were next on my list anyway :)
>
> Ah, BTW, I'm going to be travelling a lot in the next month or so, I'll
> post a schedule so that if anybody is around and want to have a beer and
> talk geek, I'm game.
>
> > Anyway, let's forget for now these syntactic problems. The important
> > thing above is that a block should provide services by means of
> > pipeline URIs and not resources.
>
> Good, I like it. Care to edit the version 1.2 of that document to show
> us what you mean also syntactically? I think that would help a lot.
>
> > > The best solution is to allow my block to explicitly "extend" that
> > > block and inherits the resources that it doesn't contain.
> >
> > Side note : we must not forget to allow a block to call
> > services/resources of its parent block (like a "super" call in Java).
>
> How do you envision this to happen? Can you come up with a real need for
> such a thing? Just checking you are designing by parallel here. In fact,
> I added inheritance after I noticed that one of my customers I did
> consulting for had a problem that could be solved wonderfully with block
> inheritance (mostly, it was block personalization for different
customers).
>
> Also, how do you make this happening? something like
>
>   <map:call resource="block:parent://whatever/service"/>
>
> would that be enough? could that be harmful or provide security concerns?
>
> > > TODO
> > > ----
> > >
> > >  1) blocks should allow to depend on 'ranges' of behavior versions.
> > > Let's try to come up with a way to describe those ranges effectively.
> >
> > IIRC, there's something in Avalon to handle this.
>
> Hmmm, not sure.
>
> Here is a possible syntax for versioning ranges of block behaviors:
>
>   1.3 -> matches version 1.3 only
>   1.x -> matches all minor versions of the first major version
>   1.(3-8) -> matches from version 1.3 to 1.8 included
>   1.(3-x) -> matches all versions higher than 1.3 and lower than 2.0
>
> which can also be applied to block versions
>
>   1.3.340 -> matches bugfix 130 of minor version 3 and major version 1
>   1.3.(48-x) -> matches from bugfix 48 on
>
> NOTE: multiple ranges are semantically meaningless, for example
>
>   (2-3).(3-x)
>
> since there is no semantic correlation between the same minor versions
> if done on different major generations. Or, at least, there should be
none.
>
> So, if you say:
>
>   this block implements http://myblocks.org/pdf/2.(3-x)
>
> you are infact indicating that your block implements all 2.x versions of
> the behavior starting from 2.3 and up to 3.0 excluded.
>
> > Ok. I hope this time this notion of "pipeline services" will go
> > further and that we will solve the misunderstanding we had 4 months
ago...
>
> Yeah, I think it will. Last time you threw in the syntactic concern
> hoping that others understood the semantic concern underneath it, but
> this time is definately clearer :)
>
> --
> Stefano Mazzocchi                               <stefano@apache.org>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message