Events posting
Gert-Jan de Boer
During the building of the MPD Connectort we ran into something I
think is weird.
The POST communicator seems to post an event every inquiry cycle and
for all the current devices found in the room.
Is this done on purpose, is there a specific reasoning behind this?
I would find the POST plugin 100 times more usefull when it only
outputs events when there actually are events. For example and device
joining or leaving the room. This way you don't have to manage which
devices are new in the room and which devices haven't changed in every
Application.
Regards,
GJ
Sexybiggetje
configuration with just some adjustments (it needs to keep track of
devices, which it currently does not fully do if im not mistaken). But
there is something else. MPD Control is a single application which
maintains state thru a temporary file, in the current situation we can
easily just rewrite the temp file fully if something changed (we do
the change check at the application not at the daemon, which is only a
few lines of code). But managing the users would be a little more
complex if you register changes, because when you restart the server
it doesn't know the changes anymore, so you would need some
initialisation event.
Flow:
- 1..1 event "all current devices" on first poll
- 1..n event "in_range" / "out_range" / "idle_time_reached" on
subsequent polls
Would this be a situation that satifies your post ?
Sexybiggetje
desired situation:
Server starts up, does initial poll and announces devices. Initial
announcements are just a bunch of events which are the same as the
other events.
One single event will be posted per devices (a server would easily
take a few hundred of these posts). Any subsequent changes will be
single events as well.
A single event just carries the same data as post/httpd/httpxml
modules (Deviceaddress, Devicename, Devicezone, Time). In addition to
the default parameters we should incorporate the existing event type
"in_range", but supplement this with "out_range" and
"idle_time_reached".
This causes the Roomware server to be responsible for managing client
data, instead of what happens with the current post module (the
responsibility is with the application, because there are only
"in_range" events and no cleanup when clients leave).
When looking at the post module I saw some of this thought has been
implemented. I'd really like one of the regular dev's to take a look
at this or explain the thought behind the current method used by the
post module. And perhaps at server bootup we need to find a way to
post these events concatinated (perhaps we could post the event as an
xml or json using the same thought as httpd module I added, and just
post a single key called "data" in which we encode the xml/json ?). So
I'd like some input on this.
Tom Burger
Just back from my 2 week holiday in Scotland! :) Pretty much activity
on roomware! Looks like I have some things to catch up with.
POST COMMUNICATOR
The post communicator should only send events. Thus when a device
is found this is pushed to some script (likely: PHP or Flash). No
double events are posted. When a device is lost and later is found,
only then the second in_range event will appear after the post
communicator has also pushed the out_range event.
When using the post communicator, you need also the httpxml
communicator. What you should do is: first obtain the list of
currently detected devices using httpxml. Second the post communicator
will inform you of updates.
IDLE TIME REACHED
Only bluetooth has the notion of "idle time reached". This is not a
feature supported by the RoomWare server. A module detects devices,
and thus a device is detected or not.
The introduction of "idle time reached" is due to bluetooth. When
scanning for Bluetooth devices, you are not 100% sure to get all
devices in range (that logically would respond). This is more like 90%
when you have multiple devices. The "idle time reached" is just when a
device fails to respond within this interval, it is very very likely
that the device is gone and not that is fails to answer all inquiries;
and thus a out_range event is thrown.
The name "idle time reached" should probably be named "max
bluetooth response interval".
HTTPD COMMUNICATOR
Good work from Sexybiggetje! This weekend I will review your code
and add it to code. I will replace the httpxml with your httpd
communicator.
Regards, Tom
--
Ga online kleding passen op http://www.mimicme.nl/ !
Tom Burger | t.bu...@mimicmedia.nl | +31 (0)62 412 20 27
Mimic Media | in...@mimicmedia.nl | Panamalaan 5-P | 1019 AS Amsterdam