**** BEGIN LOGGING AT Thu Oct 08 02:59:58 2009 Oct 08 04:15:42 ah, those must be linux-only Oct 08 04:16:27 need to figure out what #ifdef guard I need to support B2500000 baud rates Oct 08 05:37:48 so if I wanted to adapt g1 for a similar modem where would I start? Oct 08 05:38:06 one of things that needs disabled is AT+CFUN=0 as that shuts off the device Oct 08 05:44:14 look into any one of the fully functional plugins Oct 08 05:44:46 The calypso / g1 for UART example Oct 08 05:44:54 The mbm for USB / udev example Oct 08 05:45:25 is it enough to copy g1.c? Oct 08 05:45:40 as a start yeah Oct 08 05:47:06 ok, getting git and a toolchain on the device Oct 08 05:47:16 yuck :) Oct 08 05:47:23 yeah, well Oct 08 05:47:25 I'd use ser2net first ;) Oct 08 05:47:32 what is that? Oct 08 05:47:41 exposes serial port over tcp Oct 08 05:47:52 ah, that might help Oct 08 05:47:56 can even handle 0710, etc Oct 08 05:48:05 don't need any mux Oct 08 05:48:20 Most of my freerunner development was using ser2net Oct 08 05:48:39 Only the final plugin integration (serial port setup, power on) was done on the device Oct 08 05:48:41 I have ubuntu jaunty, using it now to ssh to my irssi computer Oct 08 05:48:44 over ppp Oct 08 05:49:28 ubuntu jaunty on the device I mean, ports.ubuntu.com Oct 08 05:49:55 so should be able to run ser2net then Oct 08 05:50:24 yeah, ok Oct 08 05:50:43 that might make development eaiser, if I can keep the host dbus seperate somehow Oct 08 05:50:55 but not running ofono on host, so I guess it doesn't matter Oct 08 05:51:01 Just an idea, I hate doing cross-compilation unless I have to :) Oct 08 05:51:31 well, Im doing natieve :) Oct 08 05:52:09 where is ser2net though, I still need gcc at least to build it Oct 08 05:52:36 dunno, grabbed the source and cross-compiled it Oct 08 05:54:20 http://ser2net.sourceforge.net/ Oct 08 05:54:29 how did you get the host ofono stack to recognize it? Oct 08 05:55:04 just hack modem.conf, follow the calypso trail Oct 08 05:55:39 ok, so if I add a new .c file and the ops struct with my name, that becomes the section name in modem.conf? Oct 08 05:55:57 Yep Oct 08 05:56:31 Also, you might need to hack plugins/modemconf.c to substitute a different modem driver Oct 08 05:56:41 Right now the tcp trick only works with phonesim and calypso Oct 08 05:57:59 ok Oct 08 05:58:15 plugins/phonesim.c maybe too, its pretty self explanatory once you dive into it Oct 08 05:59:59 sure, as soon as I get it checked out Oct 08 06:00:17 I've been reading through on gitweb and it looks clean enough for me to understand it Oct 08 07:04:25 ser2net won't run without syslog? Oct 08 07:04:35 denkenz: ? Oct 08 15:03:45 tmzt: no idea about syslog, since its a daemon I imagine it does need it Oct 08 15:09:03 it would really be nice if there was some sort of notification that powering up was finished :( Oct 08 15:09:17 with the dbus api Oct 08 15:21:28 like the fact that you get Powered = true PropertyChanged signal? Oct 08 15:24:17 hm, does it signal that? i hadn't noticed Oct 08 15:24:38 Also, SetProperty doesn't return until it succeeds Oct 08 15:26:49 i suppose it would be racy to assume that PropertyChanged Powered=true would be in any way related to the order of PropertyChanged SubscriberNumbers Oct 08 15:27:22 say what? Oct 08 15:27:48 nothing, just thinking aloud Oct 08 15:28:35 You get a PropertyChanged with Interfaces whenever a new one is added / removed Oct 08 15:28:57 You can then GetProperties on the interface and listen for the PropertyChanged signal Oct 08 15:29:39 You cannot assume that subscriber numbers are there or aren't there Oct 08 15:29:58 Since this depends on the SIM, modem driver, etc Oct 08 15:31:29 sure Oct 08 15:39:02 and btw, you can assume Powered will be emitted first, but unless you're prescient and know which interfaces to listen on, that doesn't really help Oct 08 17:50:40 17:27 < denkenz> Also, SetProperty doesn't return until it succeeds << wont you risk a timeout? Oct 08 17:51:11 we set a 20 second timeout on modem powerup / powerdown Oct 08 17:51:26 We return the method call then Oct 08 17:51:45 However, some method calls will need large timeouts, simply because hardware is slow Oct 08 17:51:50 e.g. Phonebook.Import Oct 08 18:02:49 denkenz: you could return immediatly from the method and then send a signal with the results Oct 08 18:03:37 Uh, have you checked what Phonebook.Import does? There's no way oFono is informing the whole world of 100+ vcards Oct 08 18:03:43 Get better DBus bindings Oct 08 18:16:53 ok Oct 08 21:58:03 denkenz: that doesn't necessarily follow - match rules let processes choose which signals they receive. Oct 08 21:58:29 but in this case, a longer timeout is preferable, given the information is not of fringe interest to any other processes Oct 08 21:58:46 I know, but plenty of bindings will register to signals they don't care about Oct 08 22:01:00 For certain methods you simply have to live with a high timeout, especially those that query the network or the SIM Oct 08 22:09:40 well, those people can get better D-Bus bindings... :P Oct 08 22:09:56 shrug, my point exactly ;) Oct 08 22:10:14 actually we're writing a patch for dbus-glib to stop it from matching * signals on every proxy you create Oct 08 22:10:20 its almost like someone should've done that sooner Oct 08 22:11:34 nod, but that's only part of the problem. Certain qt bindings had this too, where they would register for signals regardless of whether anything was actually receiving the said signal Oct 08 22:12:39 well its a sizable proportion of potential users Oct 08 22:12:59 you can't argue "get better bindings" in favour of one API if that argument applies equally as much to the alternative Oct 08 22:13:36 that was all I was pointing out - telepathy has long-running methods which need a long timeout because they round trip to the network Oct 08 22:14:01 my point is, all bindings are bad in some way. Hence it is important for us to design the API that doesn't let you shoot yourself in the foot (easily anyway) Oct 08 22:14:06 when its appropriate, and in other cases, it has methods where many people can say "oh, get this for me" and it will emit one signal when its done Oct 08 22:14:22 like avatars, where when the hash changes everyone wants the new one Oct 08 22:17:09 again, I think we agree ;) Oct 08 22:17:31 oFono tends to only use signals for property changes, but there are a few exceptions Oct 08 22:19:37 aye Oct 08 22:19:56 I was wondering, why are these not dbus properties? Oct 08 22:20:08 which? Oct 08 22:20:12 well, all of them Oct 08 22:20:25 I was talking with marcel in finland about adding a standard/agreed interface with a property changed signal Oct 08 22:20:37 to add change notification to ...DBus.Properties properties Oct 08 22:20:56 and you could use an annotation in XML to let people/bindings/etc know when they could expect this signal Oct 08 22:21:28 I don't really have a problem with that, last I looked into DBus properties they were kind of nasty Oct 08 22:21:28 (some stuff you want a more specialised signal, like telepathy's list of members in a chat room has added/removed rather than a new list of 700 #ubuntu folks) Oct 08 22:22:24 + code similarity betwen ofono / connman / bluez Oct 08 22:22:33 If holtmann adds property support to gdbus, we can switch Oct 08 22:22:46 "kind of nasty"? Oct 08 22:23:04 how does gdbus have any better support for ofono properties than dbus properties? Oct 08 22:23:31 denkenz: Actually gdbus has property support already, but it is not good enough. Also I wanna see an upstream D-Bus spec. for handling the Changed signal. Until that is part of the spec. I don't even bother. Oct 08 22:23:46 given there's no actual common API, just some methods/signals that turn up on different APIs Oct 08 22:24:03 holtmann: its not a hard thing to add, and it can be an extension very easily Oct 08 22:24:12 again, the reason is historical. The code style is basically the same between ofono / connman / bluez Oct 08 22:24:40 yeah but this is the same kind of issue again and again, why not just fix it once and all will be sweetness and light Oct 08 22:24:53 I look forward to your patch Oct 08 22:25:06 Robot101: I know, we all agreed on it, but someone has to update the specification at some point. Nobody is doing and I can't really be bothered. Personally I think how D-Bus properties are designed is actually bad from a binding point of view. Oct 08 22:25:38 holtmann: well I think how libdbus, introspection, and the daemon, is bad from a lot of points of view, but this is pretty damn trivial to fix Oct 08 22:26:25 we've killed loads of roundtrips in telepathy by moving on to real dbus properties and signalling them opportunistically eg when new stuff turns up Oct 08 22:26:32 Robot101: It is not. Please go back to the original discussion in the mailing list. Since we do have to do extra annotation between properties that are guaranteed generate a changed signal and the ones that don't. Oct 08 22:27:06 yes. so you can add that to the spec and then you can work out where you care about implementing it Oct 08 22:27:16 ofono seems like it could be a good candiate - we could use it a lot in tp too Oct 08 22:27:26 Robot101: Real D-Bus properties and oFono/BlueZ/... properties. What is the difference? Oct 08 22:27:46 holtmann: you bind it once, or you have to bind it every time you pick up a different service Oct 08 22:28:19 there won't be a difference service though Oct 08 22:28:22 Robot101: That is a binding problem. Oct 08 22:28:46 Everything is housed in ofonod, we're not a spec Oct 08 22:28:47 The low-level D-Bus lib doesn't have that problem. Neither do you have it with Python. Oct 08 22:29:10 win 12 Oct 08 22:29:11 denkenz: different service like using connman or ofono or whatever Oct 08 22:29:36 so the properties are different anyway, what is it buying you? Oct 08 22:29:45 holtmann: its not just a binding problem, its an interface problem. if org.marcels.next.service has methods called SetProperty, GetProperty, bla bla bla Oct 08 22:29:58 holtmann: how the hell are bindings meant to know these are properties and should be exposed as such? Oct 08 22:30:20 holtmann: it obviously doesn't make sense to make bindings support reinvented properties interfaces bolted onto other interfaces Oct 08 22:30:32 holtmann: it makes sense to fix *the* properties interface and then bind it everywhere properly Oct 08 22:30:57 Because that is what our documentation tell you to do. And if you show me client bindings that handle D-Bus properties properly, then we can talk. Otherwise this is just pointless. Oct 08 22:31:21 nobody is ever going to implement bindings that use properties if they're broken and nobody uses them Oct 08 22:31:29 Btw, one thing I _hate_ about DBus properties is everything is under 1 interface Oct 08 22:31:30 you have to fix the properties to make them worth binding Oct 08 22:31:33 Robot101: Go ahead and fix the properties interface. I tried, we never got anywhere and so I gave up. Oct 08 22:31:35 Breaks the whole point of OOP Oct 08 22:31:53 And doesn't really help bindings anyway Oct 08 22:32:15 If you want to truly model it in a language of choice you have to do it by hand Oct 08 22:32:18 that much isn't brilliant, but it's what's there, and unless dbus interfaces supported, er, inheritance, you fail Oct 08 22:32:47 bindings can export properties properly if they had a proper mapping between objects and interfaces Oct 08 22:32:54 denkenz: That is my problem to. You have to bind to two interface if you do properties and then method calls. Stupid. Oct 08 22:33:18 yeah, they should simply extend the interface spec with properties Oct 08 22:33:21 if your proxy supported multiple interfaces (proper OOP) that would be totally hidden Oct 08 22:33:22 Instead of inventing some hack Oct 08 22:33:24 Robot101: Which bindings are exporting properties (client point of view) properly? Oct 08 22:33:41 Which is what I meant by 'kinda nasty' btw ;) Oct 08 22:33:48 holtmann: which services are, if there's no change signal yet? :P Oct 08 22:34:24 holtmann: I don't know of many - we have utility code for it in tp-glib because dbus-glib doesn't have it, because the model is broken (multiple DBusGProxies for different interfaces on the same object) Oct 08 22:34:28 Robot101: You don't get what I mean. So even when using dbus-glib and GObject, I can use GObject property model to set/get properties on the object. Oct 08 22:34:56 holtmann: where as TpProxy is one object for each dbus object, so it makes more sense to have properties there Oct 08 22:34:59 Robot101: And that is my point exactly. You have to invent your own bindings. That is as good as we using GetProperties(). Oct 08 22:35:23 no, these would work for anything that used the dbus properties interface Oct 08 22:35:40 Go ahead and fix these things and I will be switching these things over quicker than you think. However until then it stays this way. Oct 08 22:35:57 which things? all bindings? Oct 08 22:36:15 why can't we just fix the interface and then there's actually a non-zero incentive to implement it in bindings? Oct 08 22:36:16 At least dbus-glib and python. Don't know much about Qt actually. Oct 08 22:36:36 dbus-glib is broken because it has one proxy per (interface,object) Oct 08 22:37:10 and there are no actual gobject properties on it because there are no new gtypes for different remote interfaces Oct 08 22:37:16 Agreed. Time to fix it. Oct 08 22:37:16 ie why we want a new glib binding already Oct 08 22:38:01 All agreed to. As I said. If you start fixing it (or push something new), we will switch over to D-Bus properties quicker than you think. Until then it stays this way. Oct 08 22:38:09 this is bullshit though. we already have a library (tp-glib) which can use the *standard properties interface* which we use. we can't use that library with your API because.... .... ... some *other* bindings are broken? Oct 08 22:38:48 Do you support Changed signal in a standard way? Oct 08 22:38:49 I'm happy to solve property change notification at a dbus API level, or libdbus if it makes more sense Oct 08 22:39:21 but I don't see that this means we have to be soley responsible for fixing/rewriting all existing bindings Oct 08 22:39:29 Then please do that and we can talk about. Really I am not going any other way before that has an upstream solution. Oct 08 22:39:52 I have seen NetworkManager working around it in their own way. That is also not good. Oct 08 22:40:05 right, that's what we can do. of course we need an upstreamed change notification thing, then we can talk to other people about implementing change notification in their bindings and services Oct 08 22:40:18 but to say we need to fix all the bindings before you'll fix your service is just a bit obstructive Oct 08 22:40:34 if its worth us fixing the spec/etc so you'll fix the service, then great, lets keep talking and we'll look into it Oct 08 22:41:04 As I said, gdbus already talks properties if we want to. It is just not super great with async handling. I can fix that, but the changed signal handling is a must. Oct 08 22:41:37 right. so lets work on that in the spec and then we've got some common goal to work towards. Oct 08 22:41:57 it still doesn't really help considering oFono has interfaces coming up and down Oct 08 22:42:04 hence the property list is not static Oct 08 22:42:11 have fun with that one :) Oct 08 22:42:12 telepathy has that too Oct 08 22:42:43 so IMO the whole dbus.Properties thing is borked and should be tossed Oct 08 22:42:46 eg we discover extra interfaces once connected - TpProxy lets you add interfaces later Oct 08 22:43:16 but the introspect always has the full possible range of interfaces, otherwise you'd break the crap out of all of the bindings Oct 08 22:43:19 There needs to be proper support for interface added / removed and properties per interface Oct 08 22:43:48 we have an interfaces property on a standard interface per object, which has either change notification or defined points at which it can take a new value Oct 08 22:43:53 Otherwise the entire thing is just some hack that doesn't even expose the proper use of DBus Oct 08 22:44:24 So does oFono, but it needs to be in the D-Bus spec Oct 08 22:44:34 not something invented in oFono, telepathy, etc Oct 08 22:44:56 its almost like everyone depending on an unmaintained component was somehow harmful for everyone Oct 08 22:45:32 maybe I should take Nokia's suggestion of a D-Bus hackfest and get everyone together someplace so we can sort this shit out Oct 08 22:45:53 property changing and introspect 2.0 because the XML stuff is fail, and immutable Oct 08 22:46:21 imo that's the way to go Oct 08 22:46:30 fix it in the core rather than applying bandaids Oct 08 22:46:33 although I don't think mutable interfaces are going to map nicely into bindings unless you can separately say the max interfaces you can ever have Oct 08 22:47:20 btw, another evil thing that oFono does is omit properties from GetProperties dict Oct 08 22:47:24 given if you take a list of interfaces and actually cook a new class with all of those interfaces, its not like your proxy object can change class mid-lifecycle in (m)any type systems Oct 08 22:47:29 e.g. if the property became unknown Oct 08 22:47:48 desrt had a SOME type suggestion Oct 08 22:48:12 unknown / unreadable/writable properties was one of the "features" I added in my crack properties interface Oct 08 22:48:16 denkenz: Please don't apply the bootstrap/autoconf patch. That seems wrong to me. Oct 08 22:48:30 holtmann: Nod, anything with autoconf I leave to you Oct 08 22:48:40 holtmann: I don't wanna touch the stuff :) Oct 08 22:48:44 I take care of it once I have some free time. Oct 08 22:51:03 btw, after dealing with DCE, CORBA, Java and even D-Bus I personally feel that autogenerated bindings are just a failed idea, unfortunately it seems to be a mistake being repeated every 5 years or so Oct 08 22:52:14 there's a lot you can generate - the problem is if you start doing too much behind people's backs Oct 08 22:52:53 in tp-glib and tp-qt we have a "feature" mechanism where you can say which interfaces on an object interest you, and it only "turns them on" (gets the initial values, binds the signals) if you care about that stuff Oct 08 22:53:00 denkenz: how do you signal it when the property become unknown? Oct 08 22:53:18 otherwise you waste round trips, RAM, and battery life hooked to signals you don't need Oct 08 22:53:22 istaz_: We don't, sometimes there's just no good way Oct 08 22:53:48 istaz_: You mostly get it from context info, e.g. MCC & MNC go away once you're no longer registered Oct 08 22:54:24 Robot101: Hence why I hate bindings, you try to be too nice only to shoot performance in the face Oct 08 22:54:36 been there, done that Oct 08 22:54:38 denkenz: we're not "too nice". we're exactly that nice. Oct 08 22:54:44 you have to tell it what you want Oct 08 22:54:57 give it a year or two ;) Oct 08 22:54:57 but it's still fucking useful to have typechecked method stubs/callbacks, signal binding, etc Oct 08 22:55:45 ie we've achieved a lot and not sacrificed performance. arguing in favour of people manually constructing dbus messages like it was the 80s seems like asking people to use punched cards instead or something Oct 08 22:55:50 we have compilers for this now :) Oct 08 22:57:13 shrug, so far all generated bindings I've used were a disaster area Oct 08 22:57:27 I'll be glad if I'm proven wrong though :) Oct 08 23:06:05 holtmann: I'm thinking of ripping out the gatchat/CMUX code out of gatmux Oct 08 23:06:06 they work pretty well for us at least Oct 08 23:06:26 denkenz: Why? Oct 08 23:06:46 holtmann: To do it properly we need CMUX autodetection, e.g. advanced / basic Oct 08 23:07:08 holtmann: So we'd need to do that too, and some devices are pretty pedantic Oct 08 23:07:17 I know. We need to call AT+CMUX=? Oct 08 23:07:22 holtmann: E.g. mbm says it supports CMUX, but errors out whenever I use it Oct 08 23:07:35 holtmann: Plus there's the initial setup / reset string crap Oct 08 23:08:58 I also keep hearing of non-0710 multiplexers Oct 08 23:09:09 Which means the entire thing needs to be pluggable **** ENDING LOGGING AT Fri Oct 09 03:00:00 2009