There was an interesting issue in D-Bus, related to unicast vs broadcast signals, which led [edit: typo] to a small change in specs and which might be of some interest for D-Bus developers.
Unicast signals are not widely known and probably even less used, but they are possible.
They are useful, for instance, when you need to trigger an action from a single client, among your listeners.
Until some days ago, when a unicast signal was emitted, it was actually received by everyone listening to the signal's interface (unless a strict rule was added, unusual), waking up a number of processes which actually weren't interested in the signal.
Collateral effect, waking up cost apart: those processes might actually consider the signal as they were the actual recipient and take some action upon it. Bad.
Typical rule having this problem is "sender="org.foo,interface=org.bar".
Imagine several clients using this rule to listen to org.foo, but org.foo wanting to send a signal to :1.23 only.
Specifying destination=:1.23 for the signal object didn't really work since no dest=val was specified in the rule, allowing any destination actually matching it and all the listeners to be woken up anyway.
The problem with this situation was fixing the bad behaviour without filter out eavesdroppers, which actually wanted to receive the message even if not for them.
The solution is a sort of "eavesdrop opt-in", as Thiago proposed to add a keyword to DBusMatchRule, "eavesdrop=true|false" which defaults to false and with which the listener declares that it really wants to eavesdrop, enabling it to receive messages (including signals) not meant for it (AKA eavesdropping).
Otherwise any message (again, including signals) with a specified destination won't match a filter with no or different destination. Also a rule with a specific destination won't match broadcast messages.
In other words, by default a match rule filter will match only broadcast messages or the ones specifically for you, unless you declare your very nature of eavesdropper by adding "eavesdrop=true" to your filter rule.
This is a behavioural change and consequently means a small amend to the D-Bus spec for 1.5.x.
It also means that if you maintain some code which acts as an eavesdropper, you should fix the code adding "eavesdrop=true" to your filter.
Note that it's only for 1.5.x branch; adding the "eavesdrop" keyword to a filter sent to a 1.4.x bus will fail as the keyword is not recognized.
An example on how to deal with this change keeping compatibility toward 1.4.x (stable branch) and 1.5.x (devel branch) at the same time is shown by this bustle fix. It checks for the feature presence and prepends the keyword if supported.
Planet maemo: category "feed:2cf9adc17a4d72d9c5a2e3b76a7dfba6"
Finally, the past week Alban and I released MapBuddy 0.4
As mentioned in my previous post, now MapBuddy supports Point of Interests from OpenStreetMap.
It stores them in a sqlite3 db using its spatialite extension.
We use OSM XAPI, for which sometimes requests fail and it seems to silently ignore requests for large areas.
We are working on it :-)
"Download POIs" in the main menu will download all the OSM POIs in the shown area, which mean that you need just to centre the area for which you want to download POIs for and it will fetch them for you.
This is the only operation that will need network access and might take quite long time, depending of the size of the area. Remember that OSM dislikes very large area fetching. Please be considerate.
This means that if you're planning to have a trip to a city you don't know, what you need to do is cache its tiles at different zoom level just loading them (some improvements for this step are scheduled) and select "download POIs".
Remember to "Show POIs", which will show some of the most interesting categories (OSM features) and select any of them. Amenity and Tourist are among them. Again, improvements are scheduled.
POIs are hidden at wider zoom levels, to improve map readability on high density areas.
Some more improvements are still needed and will be added soon, in particular about speed issues at startup or when finger-scrolling the map with POIs shown and about UI.
Lot of work is still going on in the offline mode direction, a search for POIs, integration with the evopedia package, better tile caching experience, etc...
Last but not least, I'd like to thank Enrico Zini for his great suggestions!
As mentioned in my previous post, now MapBuddy supports Point of Interests from OpenStreetMap.
It stores them in a sqlite3 db using its spatialite extension.
We use OSM XAPI, for which sometimes requests fail and it seems to silently ignore requests for large areas.
We are working on it :-)
"Download POIs" in the main menu will download all the OSM POIs in the shown area, which mean that you need just to centre the area for which you want to download POIs for and it will fetch them for you.
This is the only operation that will need network access and might take quite long time, depending of the size of the area. Remember that OSM dislikes very large area fetching. Please be considerate.
This means that if you're planning to have a trip to a city you don't know, what you need to do is cache its tiles at different zoom level just loading them (some improvements for this step are scheduled) and select "download POIs".
Remember to "Show POIs", which will show some of the most interesting categories (OSM features) and select any of them. Amenity and Tourist are among them. Again, improvements are scheduled.
POIs are hidden at wider zoom levels, to improve map readability on high density areas.
Some more improvements are still needed and will be added soon, in particular about speed issues at startup or when finger-scrolling the map with POIs shown and about UI.
Lot of work is still going on in the offline mode direction, a search for POIs, integration with the evopedia package, better tile caching experience, etc...
Last but not least, I'd like to thank Enrico Zini for his great suggestions!
Yesterday I uploaded spatialite into Fremantle's extra-devel.
Spatialite itself isn't directly useful to the average Maemo user, but it ca be lot of fun if you're a developer and are interested in GIS.
Spatialite is a sqlite3 extension for geo-spatial data and compatible with OpenGIS, which means you can store any map's nodes (using a OSM nomenclature) into sqlite and use them in your application, with SQL methods that will make easier the management of the node in the map space.
For more info http://www.gaia-gis.it/spatialite/ and http://www.opengeospatial.org/
If you need something more powerful you might give a look at http://postgis.refractions.net/, but this is a bit heavy for Maemo :-p
Soon a new version of Map Buddy will be available, supporting point of interest from OpenStreetMap (theoretically any source) and using spatialite (the reason for which I uploaded it), but I'll write specifically about it in another post.
Spatialite itself isn't directly useful to the average Maemo user, but it ca be lot of fun if you're a developer and are interested in GIS.
Spatialite is a sqlite3 extension for geo-spatial data and compatible with OpenGIS, which means you can store any map's nodes (using a OSM nomenclature) into sqlite and use them in your application, with SQL methods that will make easier the management of the node in the map space.
For more info http://www.gaia-gis.it/spatialite/ and http://www.opengeospatial.org/
If you need something more powerful you might give a look at http://postgis.refractions.net/, but this is a bit heavy for Maemo :-p
Soon a new version of Map Buddy will be available, supporting point of interest from OpenStreetMap (theoretically any source) and using spatialite (the reason for which I uploaded it), but I'll write specifically about it in another post.