On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman

On Fri, 22 Oct 2010, Peter Soetens wrote:

> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=791
>
> Summary: Merging DataSource and AssignableDataSource and
> introducing data source flags
> Product: Toolchain
> Version: unspecified
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: minor
> Priority: P3
> Component: RTT
> AssignedTo: orocos-dev [..] ...
> ReportedBy: peter [..] ...
> CC: orocos-dev [..] ...
> Estimated Hours: 0.0
>
>
> I'm writing this down for future reference, It's not the current priority.
>
> This task is for solving these problems encountered by developers and users:
>
> * Properties can not hold constant values

Which is fine, as far as I am concerned! The choice whether a certain value
should or should not be changed/changeable is best represented by a
_configurable policy_ and not to be hard coded. That means that a
particular application that does not want one or more of its
properties to change, should use a "Coordination component" for making sure
its policy is followed.

So, what we _really_ need for 3.0 is very lightweight components, that (via
an appropriate toolchain) can be transformed into very efficient
implementations...

> * Data Sources are not thread-safe, nor is any primitive relying on it like
> properties or attributes.

The discussion about how to design "thread-safety" can also be reduced to a
"Coordination component" that manages the shared data according to a
particular policy.

> * Too much *DataSource classes are generated leading to long compilation and
> large binary sizes
> * For each *DataSource class be written, there must be one inheriting from
> DataSource for the const-return cases and one inheriting from
> AssignableDataSource for the non-const return cases

To be avoided! The reason why you have both is that two forms of
Coordination are being built in into the framework. Unnecessarily so.

> The solution to these things is to reduce/simplify the design of the DataSource
> hierarchy. I propose to only have DataSourceBase + DataSource<T> +
> implementations inheriting from DataSource<T> and move all functions of
> AssignableDataSource into DataSource. A flag/query system will indicate the
> nature of the DataSource, instead of the down-cast to AssignableDataSource.

The "flag" would become a choice of access Coordination. A full Coordinator
is need anyway if you want (and we _will_ want) to assign different access
rights to different clients of a particular service. The above-mentioned
tooling should be smart enough to reduce the whole Coordination component
to just a flag, in case the deployment constraints are such that such a
flag would be enough, and a full Coordination component would be overhead.

> This will allow:
> - To set flags to data sources. For example: Assignable | ThreadSafe |
> Persistent | ...

These are access/changeability policies.

> - To reduce quite some code that is duplicated for the assignable/not
> assignable case, because the implementations need to inherit each time from a
> different base
> - Have Properties which behave according to their internal data source (xref
> item 1): being persistent or not, thread-safe or not etc.
> - Smaller code size and quicker compilation time since less code will be
> generated for each type T
>
> It's not a huge undertaking since only little of DataSource is exposed in the
> API (all works through DataSourceBase, which remains unchanged), but there are
> other things to be solved first. This will be for after 2.2 at least.
>
> NOTE: the thread-safety is also discussed in bug #788 and might be resolved in
> one or the other way.

In _the same way_, that is, via explicit resource Coordination.

Herman