Re: New, generic Parameters for Hummingbird

[Lauri Kimmel]

Hi,


1. Is Parameter Encoding enum final? - For example ESTCube GS-1 uses ASCII encoding. 'Native' support in Parameter would save some transformation code which is otherwise needed.

 

2. What exactly is method getSizeInBits() used for?
 

3. Using some existing java interfaces for Parameter type might be helpful. Like java.lang.Comparable – Parameter<T extends Comparable > etc. This way there is no need to define method isValue(…).

Lauri
 

----- Original Message -----

From: Johannes Klug

Sent: 09/23/11 12:37 PM

To: humming...@googlegroups.com

Subject: New, generic Parameters for Hummingbird

 
Dear devs, 

Mark recently created a generic parameter [1], which can hold any type 
of actual "payload". 
It could simply hold a String, or an Integer, for example. It is on the 
ssm branch currently, so not yet merged into master. 

Could others please review this, and share their thoughts? Input from 
the ESTcube project would be helpful, for example. 

Cheers, 
Johannes 


[1] 
https://github.com/JohannesKlug/hummingbird/blob/ssm/src/transport/space-system-model/src/main/java/org/hbird/transport/spacesystemmodel/parameters/HummingbirdParameter.java 

[Mark Doyle]

1. Not at all, we can add an ASCII encoding. This will be used to decode and encode the data at the transport layer. Encoding will require the enum since Java strings are UTF-16, we'll have to convert it to ASCII before grabbing the byte array.

2. Getting the size of the Parameter in bits ;) The transport layer codec for packets packets requires this so it can decode a byte[] of multiple parameters. It has to be able to calculate the layout. It works vice versa too where the same codec will have to create a byte[] of a set size for the target hardware. For a business layer application it will only be useful in some kind of admin/diagnostic app. We are experimenting with decorating a simpler space system model (which contains parameters) for the codec which augments the parameters with extra information, e.g., encoding and decoding strategies. Perhaps size in bits is something we can push to the decorated codec model.

3. Sounds good. It would have to deal with comparing heterogeneous Parameter types, e.g. Parameter<Integer> and Parameter<Long> as it's used to check restrictions through the space system model. Shouldn't be a problem though. Actually, we have good reason to believe the hierarchical nature of the current model will not work long term so the isValue method may be redundant.

[Johannes Klug]

> On 27 September 2011 16:52, Lauri Kimmel <lauri....@gmx.com

> <mailto:lauri....@gmx.com>> wrote:
> 3. Using some existing java interfaces for Parameter type might be

> helpful. Like java.lang.Comparable � Parameter<T extends Comparable
> etc. This way there is no need to define method isValue(�).

On 09/27/2011 08:43 PM, Mark Doyle wrote:
> 3. Sounds good. It would have to deal with
> comparing heterogeneous Parameter types, e.g. Parameter<Integer> and
> Parameter<Long> as it's used to check restrictions through the
> space system model. Shouldn't be a problem though. Actually, we have
> good reason to believe the hierarchical nature of the current model will
> not work long term so the isValue method may be redundant.

If the Parameter class were to implement Comparable<T>, how could we
ever compare two parameters in the face of type erasure?