Hi Stefano,
Thanks for your clarifications on my questions. More comments below.
On Thu, Nov 07, 2002 at 02:12:19PM +0100, Stefano Mazzocchi wrote:
>
> > Similar to virtual-packages in Debian ?
<snip/>
> Yes. Exactly. But we will use unique identifiers to indicate those
> 'virtual-packages' to allow versioning of the contract itself. (virtual
> package is a pretty bad name for what is, in fact, a contract and not a
> real package).
Ok, sounds great.
> >>2) polymorphism: I can have different implementations of the same
> >>behavior and I can switch them simply by acting on the block manager,
> >>without having to touch a single configuration line in any block. The
> >>blocks are, in fact, sealed.
> >
> > Does the installer choose based on some policy which
> > implementation will be used, or will it require an admin to choose
> > it at install time ?
>
> It is an implementation detail. It will be up to how we want to
> implement this.
>
> Like you, I see the need for automatic deployment without human
> intervention (this is great for clustered environments). So, instead of
> installing a cob, we could install a description of the entire
> collection of cobs with all the right dependencies (much as Phoenix does
> with server description files).
Ok. This description file was what I was referring to as a profile
in my earlier email. A description of all cobs satisfying
dependancies would be great.
> > If its policy based, do you think it's worth having the possibility
> > to recommend a particular implementation due to other concerns outside
> > of functionality like performance ? defects ? etc ?
>
> I really can't see how we can do this without impacting severly on the
> neutrality of the system (and, therefore, on the communities behind
> those packages).
When I wrote the paragraph above, I was under the assumption that
block implementations were automatically selected by the installer.
Now that I understand you properly :) we wouldn't need a 'Recommands'
feature as the dependancies are satisfied by the deployment admin or
the description file you describe above, not by an automatic
installer.
<snip/>
> > Similarly if there are 2 blocks that implement the same block
> > interface, but one of them contains a known defect, being able to
> > 'Recommend' the other one might also be desirable, especially if
> > the blocks are hosted from a source the user has no direct
> > influence over.
>
> Hmmm, that would require a centralized database of all block
> implementations available worldwide! or am I missing something?
No, you didn't miss something - I misunderstood how the installer
operated. I think that's clear now.
<snip/>
> > With this approach, components are loaded and validated
> > automatically, and the container can tell you even before a client
> > requests the first component whether the request and use of the
> > component will succeed (as far as dependancies on other
> > components, context entries, component versions, etc, go).
>
> I'm in favor of any more modern solution than ECM roles, as long as this
> remains back compatible with what we have today.
Agreed.
<snip/>
> > For example, our application servers (16 of them) are restarted
> > daily
> > at 7am and it would be nice if the systems could come up
> > automatically
> > without requiring a deployment admin to answer/manually configure
> > each of the 16 systems at startup/installation time.
>
> Right. A deployment script is what you need. I would suggest the following:
>
> 1) you install things manually on one development machine
>
> 2) you test the system
>
> 3) when you are satisfied, you ask the block manager to replicate its
> status to a list of defined URIs. In this circumstance, the block
> manager of the cluster machine will act as a web service for the block
> manager of the development machine you are testing and complete
> replication can be performed transparently.
>
> But, again, these are just implementation details.
*nod*, thanks for the clarification there.
> > Will the block protocol also be networkable and allow blocks on
> > other
> > hosts to be mounted remotely ?
>
> AAHAHHHHHHHHHHHHHHHHHHHHHHGGGGGGGGGGGGGG! I knew it! I knew it!
>
> My anti-FS meter went out of scale! :)
*smile*, well, I guess someone had to ask the question :)
> >>Some design decision taken
> >>--------------------------
> >>
> >>o) NO BEHAVIOR VALIDATION:
> >>
> >>I thought a lot about it but I think that having 'behavior description
> >>languages' (such as the WSDL-equivalent for blocks) is going to be
> >>terribly complicated, expensive to implement and hard to use and
> >>enforce, even for simple blocks which don't expose a sitemap and are
> >>just repositories for informations.
> >>
> >>For this reason, there is no validation taking place: if a block
> >>implements a particular behavior and exposes it thru its descriptor
> >>file, Cocoon automatically assume it implements the behavior correctly.
> >>
> >>In the future, we might think of adding a behavior description layer to
> >>enforce a little more validation, but I fear the complexity (for
> >>example) of validating stylesheets against a particular required
> >>behavior.
> >>
> >>IMO, only human try/fail and patching will allow interoperability.
> >
> >
> > On a side subject, how about a tool that could generate a skeleton
> > block based on the block interfaces one wants to implement (ie.
> > the block.xml, sitemap.xmap, etc).
> >
> > That would make it a bit nicer for developers as the tool could
> > provide skeletons for what needs to be implemented for that block
> > to correctly implement particular block interfaces.
>
> Eh, that would be nice indeed, but the block interface is *JUST* a URI.
> Nothing more. There is no contract descriptor and this paragraph
> explains exactly why: because it would be too difficult to know where to
> stop describing the contract!
hmm.. perhaps I missed something then. If I want to write a block
that implements a particular interface (eg. myskin block which
implements the skin block interface) where is that interface
described ?
I would need to know what services are exposed so that my
implementation is complete - and I thought perhaps we could have a
tool that generates a skeleton block implementation based on the
description of these services.
<snip/>
> > It would be great if there was some synergy between Avalon & Cocoon
> > to develop/improve one/both of these containers to be suitable for
> > use in Cocoon, rather than implement our own.
> >
>
> I think everybody agrees here. I also think it would be great to count
> also Phoenix into that, althought I'm not sure on the issues there.
> Peter, what do you think?
Including Phoenix would be fine with me - I'm not as familiar with
it as the other containers and will have to dig a bit deeper
there - over to you Peter :)
> > Merlin offers better support for the meta-info approach to
> > managing components and container hierarchies, whereas Fortress
> > offers
> > better ECM style compatibility. Both don't yet handle package
> > level dependancies but I don't see any problems adding that.
> >
> > The choice of container is important though as a lot of what you
> > describe could be container concerns rather than application
> > concerns
> > (eg. package validation, versioning, classloader management, etc).
> >
>
> I'm fully aware of that.
>
> >
> > Having most of that at the container level makes it much easier
> > for Cocoon which would then become the essential core, blocks,
> > and perhaps any required container extensions, etc.
> >
> > This is where 2.1 has suffered IMO, as the 2.1 codebase includes
> > features that IMO should really be handled at the container level
> > (eg. extra avalon lifecycles, configuration file monitoring,
> > sitemap/subsitap -> container hierarchy management, etc).
> >
> > Perhaps we need to investigate a bit deeper into what the
> > container should do for us. This will allow selection of which
> > container to be a bit easier.
> >
>
> Easy here. The difference between Avalon and Cocoon is that Cocoon has a
> bigger and more focused community. Avalon framework is great. But
> everything else, well, it's fragmented like hell. It's mostly a tons of
> one-man shows. I hate that.
>
> Until this situations remains, I don't feel confortable with moving more
> stuff over to Avalon even if this makes sense architecturally.
>
> Please understand that 'much easier' highly depends on the POV:
Oh, no offense intended there, I see your point regarding the
current situation Avalon is in. What I wrote above was just based
purely on my looking through the current 2.1 codebase and my
understanding of the newer Avalon containers. Nothing negative
intended there.
In fact, a lot of newer features implemented in these newer Avalon
containers can probably be accredited to developments in Cocoon.
My point (which I'm sure you're fully aware of) was more to outline
that container migration could result in us decreasing parts of the
core codebase because many things we've implemented in 2.1 that
essentially extend ECM are natively available at the container
level - if possible, and where it makes sense, I hope we can
capitalize on that.
> > Once I get our admin app up and running here at the bank I'd be
> > happy to look deeper into this.
>
> Great! That would be *very* helpful!
No problem. Once I get this admin app up and going (soon) I'll take a
look at it.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
