[01:20:20] *** Parts: twoelk (~twoelk@p5b2fbb8e.dip0.t-ipconnect.de) ("No boundaries on the net!")
[02:11:19] *** Quits: Lutin (~Lutin@lfbn-lyo-1-1261-242.w86-248.abo.wanadoo.fr) (Quit: Going offline, see ya! (www.adiirc.com))
[05:42:09] *** Quits: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) (Ping timeout: 260 seconds)
[05:54:50] *** Joins: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt)
[07:46:44] *** Quits: ilovekiruna (~ilovekiru@ip1f12afe2.dynamic.kabel-deutschland.de) (Quit: Konversation terminated!)
[08:19:34] <mvglasow> jkoan what benefits do you see in splitting it off?
[08:19:41] <mvglasow> stable APIs are a good idea, of course
[08:20:15] <mvglasow> my main concern would be builds like Android, where we currently bundle everything native into one single .so
[08:21:09] <mvglasow> as for the sensor plugins, we would need to somehow be able to enumerate all sensors
[08:21:36] <mvglasow> something like being able to go through all navit.sensor instances
[08:26:14] <mvglasow> if a general plugin can solve that, then that is OK
[08:26:53] <mvglasow> but a requirement will be to know what sensors are present, and what type of data they can supply
[09:04:36] *** Joins: Lutin (~Lutin@lfbn-lyo-1-1261-242.w86-248.abo.wanadoo.fr)
[11:56:01] *** Joins: udovdh (~udovdh@2001:981:a812:0:213:3bff:fe0f:9fb1)
[13:05:02] *** Quits: udovdh (~udovdh@2001:981:a812:0:213:3bff:fe0f:9fb1) (Quit: Leaving)
[15:40:07] *** Joins: twoelk (~twoelk@p5b2fbb8e.dip0.t-ipconnect.de)
[22:56:00] *** Quits: twoelk (~twoelk@p5b2fbb8e.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
[22:56:08] *** Joins: twoelk (~twoelk@p5b2fbb8e.dip0.t-ipconnect.de)
[23:44:45] *** Parts: twoelk (~twoelk@p5b2fbb8e.dip0.t-ipconnect.de) ("No boundaries on the net!")