owntracks with rabbitmq server about owntracks

[jpmens]

If we added a switch we'd probably end up in switch hell, having to support dozens of strange configurations of the different broker variants and their quirks. I don't think we want to do that, in particular because RabbitMQ is probably the least-used back-end for the OwnTracks apps. (I say "probably" on purpose as we have no metrics obviously.)

[joe-average-user]

Well, I do understand your point. But maybe it would be very simple if you make it a "compatibility" switch where one can simply select the "type of patch" he needs. So you would end up with only one additional switch for all coming patches of this kind. Really for the users this would be very handy as it can be described very simple in some docs. "Select Compatibiliy: RabbitMQ"
Not?

[binarybucks]

What‘s wrong with setting a suitable value for subTopic?
You can even provide a .otrc file that does that.

[joe-average-user]

I know this is quite hard for tech people to understand, but most of the mobile users are no techies. If you often talk to people with low tech background you may be able to explain how to setup the standard input of owntracks, but the config editor is definitely a step too far. And as far as I understand the issue there would not even be a drawback using "owntracks/+/#" generally in owntracks as standard setup. I mean it includes the current setting in subscription and does not harm current installations, does it?
I mean "owntracks/#" would work as well, so why not?

[jpmens]

What is quite hard for non-tech people to understand, joe-average-user, is that tech people don't like having to add features, change features, or otherwise be told "why not" without a real incentive to do so, particularly since it's always non-tech people who don't understand that we tech people, in the Open Source world, do this without payment or other benefits.

So why not?

[jpmens]

That said, if you provide a pull-request for our apps (both Android and iOS) we will entertain the idea of applying the patches.

[joe-average-user]

Well, I understand your point. And in fact I do GPL and open source programming since about 35 years in all kinds of projects. The thing is: not one of them is related to apps on mobiles. I am no Java guy and I guess (without checking) your app has zero to do with C or Assembler ;-)
So I'd probably need days to weeks to do a simple patch like this, for which people with indepth knowledge of the source probably need 10 minutes - which includes a cup of coffee :-)
For sure the .otrc file would need even less time (even for me), but judging the outcome it is not the right solution, it would end up as a solution...
Is there a real technical reason for not using "owntracks/#" in the first place? I mean do you know use cases of deeper topics or plan some? owntracks///XYZ?
If not I just proposed to save 2 bytes of code ;-)

[joe-average-user]

Ok, I read your booklet and was a bit surprised, about you arguing in this topic. Your own docs state that you need "owntracks/#" as subscription topic if you want to see waypoints. So actually you are preventing your own features by using "owntracks/+/+" as default. Me personally think your point-of-view changed from valid to ... well ... ridiculous? I mean, come on, you tell the users to use it, so in fact not only the rabbitmq server users need it, but simply everybody that wants your full features!

[binarybucks]

Apps subscribe to owntracks/+/+/waypoint to receive them. The documentation you refer to just hints that you can subscribe to /# if you want to get them with another client.

We’re internally discussing if things break when we change the default sub topic to /#.

[joe-average-user]

Please forgive my ignorance, but:
(from the booklet, waypoints)

Subscribers to the broker (our apps and any other program) can avoid getting waypoints by subscribing to, say, owntracks/+/+; also broker ACLs can prohibit access to owntracks/+/+/waypoint for particular users if so desired. Conversely, all messages published by the apps (location and waypoint) are available with a subscription to owntracks/#.
(end)

Clearly the first sentence tells that subscribing to "owntracks/+/+" avoids getting waypoints and states "our apps" explicitely. It may well be that I am getting this wrong not being native english speaking. But to me this reads like "owntracks will not get others waypoints if subscribing with owntracks/+/+", not?

For sure I do have a problem understanding what subscribing to waypoints really means. I tried it by changing subTopic to the said, and I cannot see others waypoints in the apps' list - and others cannot see mine. Nevertheless I get the notifications when others reach their waypoints. What am I expected to see in owntracks regarding waypoints? Should others really show up in the list?

[joe-average-user]

PS: the german translation for "waypoints" is really bad. "Regionen" really means "regions" which is semantically different. "waypoints" IMHO is better translated as "Orte" or less striking "Wegpunkte", which defines certain places whereas "Regionen" is thought of as something the size of a county or some big area.

[ckrey]

@joe-average-user I think your language is not appropriate.

If you decide to use a broker / usernames combination which are incompatible that is your problem.

We know the documentation is not perfect and the terms waypoint and region are not used consistently. We will review and update this at some point in time.

You are free to go somewhere else.

[joe-average-user]

Let me tell you this, though you might again find it inappropriate. The owntracks booklet published is really one of the best explanations for free software I read so far. It contains a low percentage tech speech and gives enough information to understand what is going on.
It rather looks like it perfectly covers up things like the discussed two bytes as rough edges in an else nice piece of software. There is few missing in fact from a users point of view, let me enumerate:

• the map is always focused to the same degree. If you zoomed in as app user and the position updates you end up at the old zoom level. I have no idea though if this is at all manageable by the software or a general problem in the used map api.
• the app should allow multiple hosts. if you exchange positions with different people chances are high they use different servers. So either you reconfigure the software frequently or you're busted. Something like host profiles with on/off function (allowing multiple on-hosts) would be very handy.
• track recording with variable record time should be integrated. It's not about full-featured track-management, that should probably be done else. But a mobile-useable have-a-look version would be nice.
  Don't get me wrong: this is a real good piece of software. I wish it would take steps to become brillant though, because all the needed pieces (including programmer obviously) are there and only some rough edges are left.

Regarding RabbitMQ: I know possibly most mqtt servers will use mosquitto for its easy-to-use approach. Unfortunately it is useless if you want a clustered environment for a high service availability. There is almost no way around RMQ then. I know RMQ for MQTT has exactly the discussed problem, and that they should probably fix it. But if it does not harm other users (or even does help them for some of owntracks own features), why not help RMQ users with a minimal patch in the meantime (of unknown duration)?
Don't feel blamed by anyone. I felt the issue should be discussed, because it might help others who would not speak up. I think compatibility that comes without a price should be achieved.

[jpmens]

Closing as not necessary in our opinion.