> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > Using this solution, and the images I supplied, if "child2" was
> > > exposed as a management interface then it can be accessed
> by "sub2",
> > > "child1", and "end". However, none of the other "sub"s would be
> > > able to see it. It forces you to be smart about what you
> expose and
> > > where.
> >
> > Sounds OK. Use case: Using Merlin as root, but wanting to use a
> > Phoenix-only component. Would like to put Phoenix in as a
> > sub-container, but still be able to access the component I
> put in it:
> >
> > Root (Merlin)
> > |
> > +--- Phoenix Embedded
> > | |
> > | +--- Component A
> > |
> > +--- Component B
> >
> > Component B should be able to see/use the service provided by
> > Component
> > A, and vice versa.
>
>
> :/
>
> I would say either make Component B hosted inside Phoenix as well,
> or make Merlin able to handle the additional contracts with
> Component A.
>
> With this arrangement, Component B would be able to see Phoenix and
> Phoenix would be able to see Component B. So indirectly, if Phoenix
> did not isolate itself (because it was not designed for embedded use)
> Component A could access Component B--but not vice versa.
>
> There are two reasons for this:
>
> 1) Mutual dependencies of components on the other is generally a sign
> that you need to merge the components into one. I.e. there is a
> design problem with the components.
Berin,
I never said they are dependent on each other. What I meant was that
I should be able to make it so that Component A can access Component B,
or vice versa. That is, I should be able to handle Component A
dependent on
Component B ***OR*** Component B dependent on Component A.
> For both of those reasons you would have a hard time
> convincing me that
> what you outlined is a ligitimate need.
Legitimate need is this:
+ Merlin and Phoenix are currently not completely compatible due to
various reasons well documented in the ML archives.
+ I do not think it is impossible for them to become compatible, but
I'm not about to bet anything on them doing so or, more importantly,
*staying* that way.
+ So, if I want to use a container I have to pick Merlin or Phoenix.
+ I want some way to create adapters for containers so that the
compatibility layer in Phoenix or Merlin is as small as possible.
+ A general "please expose this and this" for every container would
do the trick.
> I would say either make Component B hosted inside Phoenix as well,
> or make Merlin able to handle the additional contracts with Component
A.
That is a technically correct (and difficult) and politically impossible
solution.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
