[Spaceapi-devel] [hackerspaces] [SpaceAPI] v13 is coming close to its final state

[slopjong]

On 2013-06-12 09:34, slopjong wrote:
>
> Now it's still time to request new sensor types or give constructive
> feedback.

I want to share the feedback of a specific hackerspace with you.

This is how they understood the implementation of a sensor type, in 
this case the space_members type:

> "space_members": {
>   "value": 2,
>   "members": [
>     {"name": "nickname1", "location": "lounge"},
>     {"name": "nickname2", "location": "hackcenter"},
>   ]
> }

They thought that space_members is a sensor type which exposes the 
members that are currently in the hackerspace. They also thought that 
the name field would be used for the member names.

While I agree that this can be confusing the definition is meant as 
follows.

space_members is a sensor type for the amount of hackerspace members. 
If we assume that a space has active, inactive, dumb or lazy members, 
the name field allows to create multiple instances of the space_members 
sensor type by separating them by certain properties. The reference - 
maybe not so obvious - specifies the sensors as arrays so that in this 
case the sensor array would look like:


"space_members": [
	{
		"name" : "active",
		"value" : 32
	},
	{
		"name" : "inactive",
		"value" : 12
	},
	{
		"name" : "dumb",
		"value" : 21
	},
	{
		"name" : "lazy",
		"value" : 23
	}
]

A spaceapi-based app should then evaluate all these sensor instances to 
get the total amount of hackerspace members (which is true as long as 
every member belongs to one single sensor type). Since every sensor type 
has the 'location' field, this can be used for the case where a space is 
located in two different city regions - which maybe is not the case for 
your space but if have multiple locations, this field is for you.

To make it clear, the name field can be used to give a sensor a name 
which can be very useful if multiple instances of the same sensor type 
are located in the same place. This should guarantee that you always 
know what sensor instance you are dealing with.

The sensor type 'people' is for the members that are currently in the 
space. Basically the same pattern can be applied to this sensor type 
too. The location is for 'Chill room' and 'lab' (which are just examples 
;-) ) and the name field could be used to count the members on different 
tables. But I agree with you this is totally over-engineered, in reality 
I just copy & pasted this field when I wrote down the specs.

To be honest none of both sensor types allow a list of space members. I 
just didn't go far enough with my thoughts. I also think of renaming at 
least the people field.

space_member possibly will become 'total_member_count' and 'people' 
maybe will renamed to 'people_in_tha_house' or something similar :-D

And the latter one will be extended by one nested field to specify a 
name list.

Cheers,
slopjong