On 9/27/07, Simon Laws <[EMAIL PROTECTED]> wrote:
<snip>

  $1 Not sure about createDomain. It adds potential confusion. People will
> have
>      to decide when to create and when to get a domain. In out model of
> having a central representation of the domain
>      it works quite well in that in one place you "create" and everywhere
> else you "get" but doesn't work so well
>      in other models, e.g if there is no central manager and that each
> domain object holds references to all other domain
>      objects and nodes. Do you "create" or do you "get". How about we take
> this out and assume there is a different SCADomainFactory
>      impl instantiated (via newInstance) in the case where we want to do
> the
> creation step?


I agree, I'm already confused about this so any way to make it clearer or
avoid having to think about it sounds good to me. Can't it just be
getSCADomain(uri) and under the covers that gets it if the runtime can find
an existing domain with that uri otherwise it creates a new one? Thats a
fairly common pattern so shouldn't confuse anyone

   ...ant

  $2 The fundamental operation is starting/stopping components.
> Starting/stopping composites is a useful shortcut
>
>
>   $3 The same effect be achieved with the familiar pattern
>        void addContribution(URL url);
>        void addComposite(QName qname);
>        void startComposite(QName qname);
>      I see that this is a useful device in our desire to differentiate the
> operation of a node from that of a domain.
>      I actually don't mind them having very similar interfaces. The
> difference in my mind is one of scope. Dealing with a node
>      you are just deling with that
>      one runtime (a common pattern we use in out samples/tests). Dealing
> with a domain you don't care where the contributed
>      artifacts run.
>
>   $4 We haven't explored and magic domain to node allocation algorithms to
> date. How about we start with picking he next
>      node that doesn't yet have a contribution. If you run out of nodes
> its
> bad luck, i.e. implies no magic node provisioning so if you want more
> nodes
>      you have to start them manually.
>
>   $5  Can you pass null in here (or some special constant  if you want an
> association with a domain
>    that will only every have this one node in it? This is a special case
> as
> there are potentially several economies that can be made in terms of
> starting or
>    trying to connect to domain services.
>
>   $6 Has the effect of removing all configuration.
>
>   $7 Wondering if this should return the domain URL so that you get the
> domain object manually. Possibly a neater solution to $5 in that a
> different
> domain
>   factory (and domain implementation) can be introduced in the case that
> you
> know an application is only going to have domain with a single node
>
> Simon
>

Reply via email to