--- Log opened Sun Mar 31 00:00:38 2019
00:13 -!- Horwitz [~mich1@p200300EC9BE98500022268FFFE64E7C4.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]
00:26 -!- Horwitz [~mich1@p200300EC9BF82000022268FFFE64E7C4.dip0.t-ipconnect.de] has joined #navit
00:26 -!- mode/#navit [+o Horwitz] by ChanServ
04:06 -!- xenos1984 [~xenos1984@380a-af07-b493-1cdf-8780-87e7-07d0-2001.dyn.estpak.ee] has joined #navit
04:06 -!- mode/#navit [+v xenos1984] by ChanServ
06:17 -!- OLFDB [~olfdb@p200300D25F0D3300112862CAD6B6F900.dip0.t-ipconnect.de] has joined #navit
06:18 #navit: < OLFDB> Hi, can somebody give me an overview on how to add attributes to the navit.xml?
06:19 #navit: <+jkoan> Hi OLFDB
06:19 #navit: <+jkoan> What do you want to add and why?
06:21 #navit: < OLFDB> I'm working on the traffic branch and would like to make the traffic loop interval configurable. I added a traff_file module which is reading traff messages from a file that is populated by a Qz version able to run on Windows and Linux. 
06:22 #navit: < OLFDB> If the file gets larger it takes a lot of time to process the messages and the default loop is configured to 1sec which is too less.
06:24 #navit: < OLFDB> It is marked as a TODO in the source code to make this interval configurable anyway
06:27 #navit: <+Navit> <jkoan> Okay, that makes sense, but one additional idea, what about reading the file in monitor mode so only new messages are reprocessed instead of the whole file?
06:30 #navit: <+Navit> <jkoan> But for adding something to the xml configuration I only have the idea how to add a attribute and I haven't find this ether. But I know that you need to add your attribute to item_def.h and can read if with a attribute search with attr_yourname. I posted the code on a recent issue about the window position
06:30 #navit: < OLFDB> I don't know what monitor mode is...
06:30 #navit: <+Navit> <jkoan> Do you know "tail -f"
06:30 #navit: <+Navit> <jkoan> ?
06:31 #navit: < OLFDB> yes
06:32 #navit: <+Navit> <jkoan> Essentially this, only things that get added to the file after the last read are processed (in case of tail printed, in our case processed)
06:33 #navit: < OLFDB> currently I'm using the already implemented method to read traff from a file. This seems to read the whole file every time. 
06:35 #navit: < OLFDB> The best solution would be to have some kind of message interface between Qz and Navit as on Android. To have it working on Windows and Linux there is no common method for doing this I guess. 
06:36 #navit: <+Navit> <jkoan> Hm, by looking in the code, do you think that it would be possible to do another function which reads a file like a stream? That would save a lot of processing as only new things in the file needs to be processed
06:36 #navit: <+Navit> <jkoan> Like gpsd but for traffic?
06:38 #navit: < OLFDB> Yes, like gpsd. I saw there is a DBUS interface already to send traff messages, but DBUS is not available on Windows. 
06:38 #navit: <+Navit> <jkoan> Unfortunately, yes
06:40 #navit: < OLFDB> To keep things simple a file as an interface seems less complicated. I will try to implement it with reading from a stream. Nevertheless it would be interesting to know how the configuration wotks basically.
06:42 #navit: <+Navit> <jkoan> I even don't know it in full, but I told you what I know about attributes on a item
06:43 #navit: < OLFDB> I will have a look in the issue for the window position. Thank you.
07:36 -!- OLFDB [~olfdb@p200300D25F0D3300112862CAD6B6F900.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
07:50 -!- OLFDB [~olfdb@p200300D25F394700555C374D139B3CCE.dip0.t-ipconnect.de] has joined #navit
11:54 -!- OLFDB [~olfdb@p200300D25F394700555C374D139B3CCE.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
14:23 #navit: <+Navit> <KaZeR> @OLFDB here is our documentation regarding attributes : http://wiki.navit-project.org/index.php/Attributes
14:24 #navit: <+Navit> <KaZeR> I can work on an example with you
14:24 #navit: <+Navit> <KaZeR> The important thing to know is that new attributes have to be added at the end of the relevant section in attr_def.h
20:27 -!- mvglasow [~mvglasow@dslb-188-104-115-022.188.104.pools.vodafone-ip.de] has joined #navit
20:32 #navit: < mvglasow> @OLFDB great to hear someone else is working on traffic
20:33 #navit: < mvglasow> and yes, a file is not necessarily the best way to exchange information
20:34 #navit: < mvglasow> though monitor mode might work
20:34 #navit: < mvglasow> in fact, my idea was that TraFF messages would be sent as broadcasts using the platform's request broker infrastructure
20:34 #navit: < mvglasow> that is, intents on Android
20:35 #navit: < mvglasow> on Linux that would be DBus
20:35 #navit: < mvglasow> and on Windows possibly DCOM
20:36 #navit: < mvglasow> actually, we have a rudimentary Dbus implementation in binding_dbus.c
20:37 #navit: < mvglasow> it still uses directed messages rather than broadcasts
20:39 #navit: < mvglasow> and relies on a temporary file (better option would be to send XML directly over Dbus as data)
20:40 #navit: < mvglasow> but it might serve as a starting point, look for request_navit_traffic_inject() in navit/binding/dbus/binding_dbus.c
20:41 #navit: < mvglasow> have to admit that I am no expert on Dbus, and it's been decades since I did something with DCOM, though
20:42 #navit: < mvglasow> the idea is that Qz (or other apps, for that matter) supply the entire set of messages in memory only when asked
20:43 #navit: < mvglasow> and only updates otherwise (yes, this congestion is still there; that congestion has gotten longer; there's a new one here etc.)
20:44 #navit: < mvglasow> you might also want to check out https://gitlab.com/traffxml/traff
20:45 #navit: < mvglasow> which has the specification for TraFF and the ideas behind it
20:46 #navit: < mvglasow> bear in mind that TraFF was designed to allow for multiple consumers and producers
20:46 #navit: < mvglasow> maybe tomorrow OSMand has an interface as well
20:47 #navit: < mvglasow> or we have another provider over which drivers can create and share share traffic reports
20:47 #navit: < mvglasow> or one which does image recognition on variable-messsage signs and extracts image information
20:48 #navit: < mvglasow> also, I am currently working on multithreading for Navit
20:48 #navit: < mvglasow> first candidate would be traffic, i.e. traffic_process_messages_int() would run in a separate thread
20:48 #navit: < mvglasow> thus not blocking the UI any more
20:49 #navit: < mvglasow> OTOH the 1s interval then just becomes the interval for which the thread will sleep if there are no more new meessages
21:09 #navit: <+jkoan> mvglasow: you designed traffxml, right?
21:10 #navit: < mvglasow> yes, that is my work
21:14 -!- xenos1984 [~xenos1984@380a-af07-b493-1cdf-8780-87e7-07d0-2001.dyn.estpak.ee] has quit [Quit: Leaving.]
22:29 #navit: < mvglasow> @OLFDB I'd be interested in seeing your Qz port, though
23:31 -!- mvglasow [~mvglasow@dslb-188-104-115-022.188.104.pools.vodafone-ip.de] has quit [Quit: Leaving]
--- Log closed Mon Apr 01 00:00:39 2019