Ovidiu Predescu wrote:
1. I definitely agree with Sylvain's view of blocks as classes, not as
instances. I think is important to expose pipelines and not individual
resources. Sylvain explained to me why this is important when it came to
the control flow layer, which now uses only pipelines and not resources.
Yes, I agree.
2. Another question is how are we dealing with flow scripts? Are we
going to expose functions on a per-block level?
Or we consider flows as resources of the block, hence hidden from the
user, and accessible only through pipelines publicly exposed?
Yes, I like this one better as well.
I would favor the latter, as it's in line with the pipelines idea
Sylvain mentioned.
3. What is the relationship between libraries defined in a block and
those defined in the container loading it? Are they loaded by the same
classloader or by different classloaders?
Different classloaders, I would presume.
I think the latter would help isolate contracts between different
blocks, at the risk of duplicating libraries in the runtime system.
Yep, I'd like use a little more memory than having a bunch of class
versioning conflicts down the road. RAM is way cheaper than users's time
(and patience!)
The
impact should be minimal however in real life, with different blocks
serving different purposes (FO generation etc.).
Yes, exactly. Also, the container should come with a minimal set of
libraries installed, and also we need separate classloaders because two
blocks could be using two different versions of the same block for bug
reasons.
Coupled with the exposure of pipelines only, block contracts are then
well defined and separated.
Yep.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
