[Bug 791] New: Merging DataSource and AssignableDataSource and introducing data source flags

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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
* Data Sources are not thread-safe, nor is any primitive relying on it like
properties or attributes.
* 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

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.

This will allow:
- To set flags to data sources. For example: Assignable | ThreadSafe |
Persistent | ...
- 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.

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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

[Bug 791] New: Merging DataSource and AssignableDataSource and i

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