I am proposing that an empty "Ports" section in a deployment file indicates to connect ALL ports of the component. This saves typing a long list of ports for each component, as well as potentially reducing the likelihood of typo's leading to frustating debugging.
And I'm lazy. The attached cuts my XML deployment files in half. And not one of the dozens of components we use does not use all ports.
The following XML entry with a Ports block that is empty
...
indicates to connect ALL ports of HMI, saving typing them out one by one.
This version, with no Ports block, indicates to connect NO ports - no change from current behaviour.
...
and this provides the standard behaviour of specifying precisely which ports to connect
...
The only change in current behaviour is
* if you have deployment files with components having a Ports blocks that is empty, then these components will now connect all ports instead of no ports
* If you remove all individual port entries and rely on the emtpy Ports block to connect all ports, then if you specified the individual port entries in a different order from how they are added in the component's constructor, you could conceivably (maybe?) get connected to something else (I think this is likely to be a really exceptional case).
You might ask, why not fold the first two cases together? Because someone might still want to be able to say "connect no ports".
Thoughts?
Stephen
| Attachment | Size |
|---|---|
| patch-connect-all-ports.patch | 7.21 KB |
Proposal: automatically connect all ports when deploying
On Fri, Jun 12, 2009 at 3:13 AM, <kiwi [dot] net [..] ...> wrote:
> I am proposing that an empty "Ports" section in a deployment file indicates
> to connect ALL ports of the component. This saves typing a long list of
> ports for each component, as well as potentially reducing the likelihood of
> typo's leading to frustating debugging.
>
> And I'm lazy. The attached cuts my XML deployment files in half. And not one
> of the dozens of components we use does not use all ports.
I missed most of this discussion as I was spending my time (in a more
useful manner ;-) elsewhere last week, and I haven't read the whole
thread through, but just my 2 cents on this matter which haven't been
mentioned AFAIS:
- I've also lost already quite some time debugging the errors in
deployers xml file, both to errors in/unclear docs with respect to
port connecting (check bugzilla). Sometimes probably because I didn't
read the documentation well enough, but still, if "experienced" (ahum)
users like you and me are struggling with this, it's a clear omen...
- OTOH, at first sight I don't know wether your proposal is the best
solution. IMO the deployers file is something we have to be able to
_generate_ from a (G)UI instead of manually editing cumbersome xml.
So instead of creating a possibly ambiguous syntax because we're lazy,
I think we (hey, don't look at me! :-) should work a formal syntax and
a UI that reduces typos/debugging.
YMMV,
Klaas
Proposal: automatically connect all ports when deploying
On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
> I am proposing that an empty "Ports" section in a deployment file indicates
> to connect ALL ports of the component. This saves typing a long list of
> ports for each component, as well as potentially reducing the likelihood of
> typo's leading to frustating debugging.
This mechanism would only work with identical named ports across
to-be-connected components, wouldn't it ? What makes your patch
different from AutoConnect = 1 ?
I'm also more in favour of an explicit policy than an implicit one.
Peter
Proposal: automatically connect all ports when deploying
On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>> I am proposing that an empty "Ports" section in a deployment file
>> indicates
>> to connect ALL ports of the component. This saves typing a long
>> list of
>> ports for each component, as well as potentially reducing the
>> likelihood of
>> typo's leading to frustating debugging.
>
> This mechanism would only work with identical named ports across
> to-be-connected components, wouldn't it ? What makes your patch
> different from AutoConnect = 1 ?
What is this "AutoConnect" you speak of?
> I'm also more in favour of an explicit policy than an implicit one.
Fine with me. Got any suggestions?
I'm simply trying to find a way to not have to type hundres of port
names ... and are open to options.
S
Proposal: automatically connect all ports when deploying
On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>> I am proposing that an empty "Ports" section in a deployment file
>> indicates
>> to connect ALL ports of the component. This saves typing a long
>> list of
>> ports for each component, as well as potentially reducing the
>> likelihood of
>> typo's leading to frustating debugging.
>
> This mechanism would only work with identical named ports across
> to-be-connected components, wouldn't it ? What makes your patch
> different from AutoConnect = 1 ?
You can connect non-identically named ports? How on earth do you do
that? I see nothing on the web pages about this.
When did "AutoConnect" get introduced? I see it know on OCL's web pages.
S
Proposal: automatically connect all ports when deploying
On Fri, Jun 12, 2009 at 13:16, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
>
>> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>>>
>>> I am proposing that an empty "Ports" section in a deployment file
>>> indicates
>>> to connect ALL ports of the component. This saves typing a long list of
>>> ports for each component, as well as potentially reducing the likelihood
>>> of
>>> typo's leading to frustating debugging.
>>
>> This mechanism would only work with identical named ports across
>> to-be-connected components, wouldn't it ? What makes your patch
>> different from AutoConnect = 1 ?
>
> You can connect non-identically named ports? How on earth do you do that? I
> see nothing on the web pages about this.
That's the whole point of the Ports structure: to connect ports with
different names. This is how to read it:
The "name" is the port of this component, the "XX-Connection" is the
connection of which you want that port be part of. The other component
then has:
Any number of components and their ports can participate in the
XX-Connection and Other-Connections.
As such Controller.Input is connected to HMI.XX and so on.
>
> When did "AutoConnect" get introduced? I see it know on OCL's web pages.
In OCL 1.8.0. From the DeploymentComponent manual:
"The AutoConnect XML element indicates if the component's data ports
should be automatically connected to peer ports which have the same
name and type. This flag is read during the configureComponents()
step of the DeploymentComponent. Both components must have the
AutoConnect element set to 1 and one must be peer of the other in
order to trigger automatic connection of ports. It is possible that a
port is connected to one component using the Ports element and to
another component using the AutoConnect flag. If an automatic port
connection fails, the configuration procedure will not fail and just
continue. An error message may be logged. By default, AutoConnect is 0
(off)."
Am I missing something or were you missing something ?
Peter
Proposal: automatically connect all ports when deploying
On Jun 12, 2009, at 07:43 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 13:16, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
>> On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
>>
>>> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>>>>
>>>> I am proposing that an empty "Ports" section in a deployment file
>>>> indicates
>>>> to connect ALL ports of the component. This saves typing a long
>>>> list of
>>>> ports for each component, as well as potentially reducing the
>>>> likelihood
>>>> of
>>>> typo's leading to frustating debugging.
>>>
>>> This mechanism would only work with identical named ports across
>>> to-be-connected components, wouldn't it ? What makes your patch
>>> different from AutoConnect = 1 ?
>>
>> You can connect non-identically named ports? How on earth do you do
>> that? I
>> see nothing on the web pages about this.
<sni
>> When did "AutoConnect" get introduced? I see it know on OCL's web
>> pages.
>
> In OCL 1.8.0. From the DeploymentComponent manual:
> "The AutoConnect XML element indicates if the component's data ports
> should be automatically connected to peer ports which have the same
> name and type. This flag is read during the configureComponents()
> step of the DeploymentComponent. Both components must have the
> AutoConnect element set to 1 and one must be peer of the other in
> order to trigger automatic connection of ports. It is possible that a
> port is connected to one component using the Ports element and to
> another component using the AutoConnect flag. If an automatic port
> connection fails, the configuration procedure will not fail and just
> continue. An error message may be logged. By default, AutoConnect is 0
> (off)."
>
> Am I missing something or were you missing something ?
The AutoConnect doesn't operate quite the same way as the proposed
patch. Nor does it operate the same way as explicitly listing all ports.
With AutoConnect you *must* list all the peers within each component.
We have gotten in the habit of listing only one side of the peer
relationships, to decouple components.
For example
Component Camera doesn't list any peers (it doesn't care what peers it
has)
Component ImageProcessor lists only Camera as a peer (doesn't care
about the HMI)
Component HMI lists both Camera and ImageProcessor
Explicitly listing ports for each of the above, or using the proposed
patch, and the above does what you expect. Using the "AutoConnect" you
get errors like
Not a big deal, but subscribing to Herman's continual quest for
decoupling ... ;-) ... then the AutoConnect forces additional
coupling. You either have to list all ports and then you can use one-
sided peer listing, or you use AutoConnect and have to explicitly list
all peers within each component.
YMMV
Proposal: automatically connect all ports when deploying
On Fri, Jun 12, 2009 at 16:08, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>
> The AutoConnect doesn't operate quite the same way as the proposed patch.
> Nor does it operate the same way as explicitly listing all ports.
>
> With AutoConnect you *must* list all the peers within each component. We
> have gotten in the habit of listing only one side of the peer relationships,
> to decouple components.
>
> For example
>
> Component Camera doesn't list any peers (it doesn't care what peers it has)
> Component ImageProcessor lists only Camera as a peer (doesn't care about the
> HMI)
> Component HMI lists both Camera and ImageProcessor
>
> Explicitly listing ports for each of the above, or using the proposed patch,
> and the above does what you expect. Using the "AutoConnect" you get errors
> like
>
>
>
> Not a big deal, but subscribing to Herman's continual quest for decoupling
> ... ;-) ... then the AutoConnect forces additional coupling. You either have
> to list all ports and then you can use one-sided peer listing, or you use
> AutoConnect and have to explicitly list all peers within each component.
You're correct. The peers constraint should be dropped, because it's unrelated
to data ports. It was a bad idea. We have to change this.
Peter
Proposal: automatically connect all ports when deploying
On Jun 12, 2009, at 07:43 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 13:16, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
>> On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
>>
>>> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>>>>
>>>> I am proposing that an empty "Ports" section in a deployment file
>>>> indicates
>>>> to connect ALL ports of the component. This saves typing a long
>>>> list of
>>>> ports for each component, as well as potentially reducing the
>>>> likelihood
>>>> of
>>>> typo's leading to frustating debugging.
>>>
>>> This mechanism would only work with identical named ports across
>>> to-be-connected components, wouldn't it ? What makes your patch
>>> different from AutoConnect = 1 ?
>>
>> You can connect non-identically named ports? How on earth do you do
>> that? I
>> see nothing on the web pages about this.
>
> That's the whole point of the Ports structure: to connect ports with
> different names. This is how to read it:
>
>
>
> The "name" is the port of this component, the "XX-Connection" is the
> connection of which you want that port be part of. The other component
> then has:
>
>
>
> Any number of components and their ports can participate in the
> XX-Connection and Other-Connections.
So "XX-Connection" is the name of the connection, not necessarily
either/any of the ports involved? So if I had two camera components
named LeftCamera and RightCamera (say), but with the same named port
(say Image), then I could connect all ports to the HMI by using
different named connections?
> As such Controller.Input is connected to HMI.XX and so on.
That is complete news to me!!! We've wondered before if you could do
this. Huh!
Where did I miss this in the doc's? I still see nothing specific
documenting the above syntax on the v1.8 OCL deployment page.
>> When did "AutoConnect" get introduced? I see it know on OCL's web
>> pages.
>
> In OCL 1.8.0. From the DeploymentComponent manual:
> "The AutoConnect XML element indicates if the component's data ports
> should be automatically connected to peer ports which have the same
> name and type. This flag is read during the configureComponents()
> step of the DeploymentComponent. Both components must have the
> AutoConnect element set to 1 and one must be peer of the other in
> order to trigger automatic connection of ports. It is possible that a
> port is connected to one component using the Ports element and to
> another component using the AutoConnect flag. If an automatic port
> connection fails, the configuration procedure will not fail and just
> continue. An error message may be logged. By default, AutoConnect is 0
> (off)."
>
> Am I missing something or were you missing something ?
For the AutoConnect, that is my own cranial rectum extraction going on!
S
Proposal: automatically connect all ports when deploying
On Fri, Jun 12, 2009 at 09:58:32AM +0200, Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
> > I am proposing that an empty "Ports" section in a deployment file indicates
> > to connect ALL ports of the component. This saves typing a long list of
> > ports for each component, as well as potentially reducing the likelihood of
> > typo's leading to frustating debugging.
>
> This mechanism would only work with identical named ports across
> to-be-connected components, wouldn't it ? What makes your patch
> different from AutoConnect = 1 ?
I agree. Autoconnect should work at a _semantic_ level, not
syntactic. And the first is out of scope of the rtt. It's IMHO again
the task of the "advanced deployer".
Markus
Proposal: automatically connect all ports when deploying
On Fri, Jun 12, 2009 at 13:57, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Jun 12, 2009, at 07:43 , Peter Soetens wrote:
>
>> On Fri, Jun 12, 2009 at 13:16, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>>>
>>> On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
>>>
>>>> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>>>>>
>>>>> I am proposing that an empty "Ports" section in a deployment file
>>>>> indicates
>>>>> to connect ALL ports of the component. This saves typing a long list of
>>>>> ports for each component, as well as potentially reducing the
>>>>> likelihood
>>>>> of
>>>>> typo's leading to frustating debugging.
>>>>
>>>> This mechanism would only work with identical named ports across
>>>> to-be-connected components, wouldn't it ? What makes your patch
>>>> different from AutoConnect = 1 ?
>>>
>>> You can connect non-identically named ports? How on earth do you do that?
>>> I
>>> see nothing on the web pages about this.
>>
>> That's the whole point of the Ports structure: to connect ports with
>> different names. This is how to read it:
>>
>>
>>
>> The "name" is the port of this component, the "XX-Connection" is the
>> connection of which you want that port be part of. The other component
>> then has:
>>
>>
>>
>> Any number of components and their ports can participate in the
>> XX-Connection and Other-Connections.
>
> So "XX-Connection" is the name of the connection, not necessarily either/any
> of the ports involved? So if I had two camera components named LeftCamera
> and RightCamera (say), but with the same named port (say Image), then I
> could connect all ports to the HMI by using different named connections?
Exactly !
>
>
Yes. Correct.
>
>> As such Controller.Input is connected to HMI.XX and so on.
>
> That is complete news to me!!! We've wondered before if you could do this.
> Huh!
>
> Where did I miss this in the doc's? I still see nothing specific documenting
> the above syntax on the v1.8 OCL deployment page.
I'll refactor section "2.3. How each component is setup" into
subsections. It's really hard to read right now. An additional figure
to detail the port connections might help as well.
Peter
Proposal: automatically connect all ports when deploying
On Jun 12, 2009, at 08:13 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 13:57, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
>> On Jun 12, 2009, at 07:43 , Peter Soetens wrote:
>>
>>> On Fri, Jun 12, 2009 at 13:16, Stephen Roderick<kiwi [dot] net [..] ...>
>>> wrote:
>>>>
>>>> On Jun 12, 2009, at 03:58 , Peter Soetens wrote:
>>>>
>>>>> On Fri, Jun 12, 2009 at 03:13, <kiwi [dot] net [..] ...> wrote:
>>>>>>
>>>>>> I am proposing that an empty "Ports" section in a deployment file
>>>>>> indicates
>>>>>> to connect ALL ports of the component. This saves typing a long
>>>>>> list of
>>>>>> ports for each component, as well as potentially reducing the
>>>>>> likelihood
>>>>>> of
>>>>>> typo's leading to frustating debugging.
>>>>>
>>>>> This mechanism would only work with identical named ports across
>>>>> to-be-connected components, wouldn't it ? What makes your patch
>>>>> different from AutoConnect = 1 ?
>>>>
>>>> You can connect non-identically named ports? How on earth do you
>>>> do that?
>>>> I
>>>> see nothing on the web pages about this.
>>>
>>> That's the whole point of the Ports structure: to connect ports with
>>> different names. This is how to read it:
>>>
>>>
>>>
>>> The "name" is the port of this component, the "XX-Connection" is the
>>> connection of which you want that port be part of. The other
>>> component
>>> then has:
>>>
>>>
>>>
>>> Any number of components and their ports can participate in the
>>> XX-Connection and Other-Connections.
>>
>> So "XX-Connection" is the name of the connection, not necessarily
>> either/any
>> of the ports involved? So if I had two camera components named
>> LeftCamera
>> and RightCamera (say), but with the same named port (say Image),
>> then I
>> could connect all ports to the HMI by using different named
>> connections?
>
> Exactly !
>
>>
>>
>
> Yes. Correct.
Well damn! That would have saved a boatload of work on the last
project ... we had to invent components to do the renaming. C'iest la
vie!
>>> As such Controller.Input is connected to HMI.XX and so on.
>>
>> That is complete news to me!!! We've wondered before if you could
>> do this.
>> Huh!
>>
>> Where did I miss this in the doc's? I still see nothing specific
>> documenting
>> the above syntax on the v1.8 OCL deployment page.
>
> I'll refactor section "2.3. How each component is setup" into
> subsections. It's really hard to read right now. An additional figure
> to detail the port connections might help as well.
Maybe provide something like my XML file above would be useful as an
example? Although maybe that goes in a system application example ...?
Cheers
Stephen
Proposal: automatically connect all ports when deploying
On Fri, 12 Jun 2009, kiwi [dot] net [..] ... wrote:
> I am proposing that an empty "Ports" section in a deployment file
> indicates to connect ALL ports of the component. This saves typing a long
> list of ports for each component, as well as potentially reducing the
> likelihood of typo's leading to frustating debugging.
I feel more for a policy that indicates the wishes of the programmer
_explicitly_, for example by using "ConnectAll" and "ConnectNone" tags, or
something similar. Implicit actions are seldom a good idea...
Herman
> And I'm lazy. The attached cuts my XML deployment files in half. And not one of the dozens of components we use does not use all ports.
>
> The following XML entry with a Ports block that is empty
>
>
>
> indicates to connect ALL ports of HMI, saving typing them out one by one.
>
> This version, with no Ports block, indicates to connect NO ports - no change from current behaviour.
>
>
>
>
> and this provides the standard behaviour of specifying precisely which ports to connect
>
>
>
>
> The only change in current behaviour is
> * if you have deployment files with components having a Ports blocks that is empty, then these components will now connect all ports instead of no ports
> * If you remove all individual port entries and rely on the emtpy Ports block to connect all ports, then if you specified the individual port entries in a different order from how they are added in the component's constructor, you could conceivably (maybe?) get connected to something else (I think this is likely to be a really exceptional case).
>
> You might ask, why not fold the first two cases together? Because someone might still want to be able to say "connect no ports".
>
> Thoughts?
> Stephen
>
>
>