From cocoon-dev-return-32610-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Sun Nov 03 22:21:00 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 16227 invoked by uid 500); 3 Nov 2002 22:21:00 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 16216 invoked from network); 3 Nov 2002 22:20:58 -0000 Message-ID: <06b301c28387$7733eaf0$0100a8c0@MAUCHI> From: "Ivelin Ivanov" To: References: <3DC31859.2040707@apache.org> <3DC45AF7.5050700@anyware-tech.com> <3DC52B01.6070904@apache.org> Subject: Re: [design] Cocoon Blocks 1.1 Date: Sun, 3 Nov 2002 16:22:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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" To: 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). > > > > > > > > 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 > > > > 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 > -------------------------------------------------------------------- > > > > > --------------------------------------------------------------------- > 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