**** BEGIN LOGGING AT Wed Jan 06 02:59:57 2010 Jan 06 02:59:57 fantastic. Thank you very much for your time :) Jan 06 03:00:13 you're welcome Jan 06 03:04:25 hey Jan 06 03:24:06 http://wiki.maemo.org/User:Jebba/Ofono Jan 06 05:43:55 denkenz: if there's things that can be stored in the sim in both a GSM mandated and CPHS mandated file, should we try to store in both? Jan 06 05:44:48 also do we return success if we only manage to write to one of the files? Jan 06 05:47:19 (that's what Android does apparently, return success if either write succeeds) Jan 06 06:38:11 balrog-kun: I'm really not sure how relevant CPHS is, it has been folded into 3GPP specs Jan 06 06:39:01 balrog-kun: So lets do what is easiest to support it Jan 06 06:39:32 yeah, it seems like something that was supposed to remedy some holes in the spec and later new version gsm based on it Jan 06 06:39:56 denkenz: the easiest thing would perhaps be write the CPHS version of the file as a side effect and discard the result Jan 06 06:40:11 i.e. ignore any errors Jan 06 06:40:33 sounds fine to me Jan 06 06:55:30 balrog-kun: is that from android logcat? Jan 06 06:56:24 tmzt: nope, looking at the sources in their git Jan 06 06:56:33 tmzt: java stuff Jan 06 06:56:42 oh, it's in rilj Jan 06 06:56:56 you working on g1? Jan 06 06:57:35 tmzt: nah, just comparing the sources to see how they handle this situation, as a data point Jan 06 06:57:53 ok Jan 06 06:58:12 i've never actually played with android Jan 06 06:59:43 I just want to get one driver that works on varied msm devices so I don't have to support so many Jan 06 06:59:49 balrog-kun: Did I apply all your patches before new years or did I miss some? Jan 06 07:00:17 denkenz: i think there was one more, let me check Jan 06 07:04:24 denkenz: this is one: http://lists.ofono.org/pipermail/ofono/2009-December/000943.html Jan 06 07:05:12 That's the cache by phase one? Ok Jan 06 07:05:27 Was the CBS Topic stuff squared away? Jan 06 07:05:46 denkenz: here's one more which you commented on but i replied i thought the way the patch did it was okay http://lists.ofono.org/pipermail/ofono/2009-December/000924.html Jan 06 07:06:16 the second one is the CBS Topics thing Jan 06 07:06:58 Ok, the flow of that one needs tweaking Jan 06 07:07:37 Can you read the Topics string at initialization and only fire off cbmi / cbmir if it is non-existent? Jan 06 07:09:17 denkenz: that would make things simpler but discard changes made on the sime outside ofono Jan 06 07:09:26 sim* Jan 06 07:09:46 obviously that isn't big deal Jan 06 07:10:39 balrog-kun: Your patch does that anyway ;) Jan 06 07:11:07 denkenz: ah right, i'm trying to read it and remember what it does exactly :) Jan 06 07:11:53 Hence my later comments Jan 06 07:12:01 Also, you're not doing anything with cbmid still Jan 06 07:12:09 So fix that one up and resend Jan 06 07:13:21 i'll update and send a new version Jan 06 07:13:28 ofono_cbs_notify handles CBMID though Jan 06 07:13:48 (in git already) Jan 06 07:13:52 Do you ever append cbmid to the topic list? Jan 06 07:14:14 yeah, in cbs_topics_to_str Jan 06 07:14:25 Ah ok, then nevermind that comment Jan 06 07:14:29 the initial patch i send missed this part Jan 06 07:14:35 sent* Jan 06 07:15:30 denkenz:do you plan to implement oFono interface for CDMA? Jan 06 07:15:50 CDMA is not a priority for us right now Jan 06 07:16:07 If anyone wants to make it work, patches are welcome Jan 06 07:16:14 We have our hands full with GSM still Jan 06 07:18:49 11•12denkenz11• Is CDMA network registration included now? Jan 06 07:19:27 balrog-kun: Ok, then just make the change to read Topics right away Jan 06 07:19:34 it's mostly the same Jan 06 07:19:55 nice ansi, haven't seen that before Jan 06 07:19:59 balrog-kun: Also, I noticed some modems do not allow CBS commands until we have network registration Jan 06 07:20:27 patches would follow api direction Jan 06 07:20:29 balrog-kun: So we might have to play the same tricks as with GPRS Jan 06 07:20:34 but we don't get that either Jan 06 07:21:16 denkenz: aha, i'll check that Jan 06 07:21:50 balrog-kun: Don't remember which one I saw this with, either mbm, hso or the Freerunner Jan 06 07:22:06 balrog-kun: That's the only ones I had while in Oz Jan 06 07:23:18 JohnnyLo: I've never even looked at the CDMA specs actually, so if it works it will be by luck, not design on my part Jan 06 07:23:28 Again, patches are welcome Jan 06 07:23:42 modem-deprived :) Jan 06 07:24:09 balrog-kun: Heh, well that's fixable, I'm network deprived Jan 06 07:24:12 it's just at, the pdp contexts are different (fake) Jan 06 07:24:23 cfun=0 shuts off device, use 99 for ps Jan 06 07:24:31 no sim car of phonebook Jan 06 07:24:36 balrog-kun: So I can't do any testing of CBS myself ;) Jan 06 07:24:42 mostly no registration Jan 06 07:26:14 tmzt: Sounds like you need to make a proof-of-concept driver ;) Jan 06 07:26:40 I started to for raph500 Jan 06 07:26:47 tmzt: And changing core APIs isn't out of the question for CDMA support Jan 06 07:26:58 right, but in what way? Jan 06 07:27:19 Don't know until someone proposes something Jan 06 07:27:33 Or points out what doesn't work Jan 06 07:27:39 I can't test it right now I only have one smartphone and I use it as a phone Jan 06 07:28:10 if somebody else wants to work on it I'm happy to help Jan 06 07:28:31 11•12denkenz11• is changing core APIs for CDMA support welcomed? or leave it as it is prefered? Jan 06 07:29:14 None of the APIs are frozen, if they need changing then we change them, simple as that Jan 06 07:29:38 it's mostly whether certain thins are needed Jan 06 07:29:47 I don't thing registration is Jan 06 07:30:26 so it shouldn't be called by core, noping rather than null is not prefered Jan 06 07:30:51 it there a type or protocol field in the driver struct? Jan 06 07:31:16 also, some chips like mine support both modes and even simulataneouly depending on configured mode Jan 06 07:31:50 so a driver that works with both modes but registers only the working ones for callbacks is preferred Jan 06 07:32:06 modes = cdma and gsm Jan 06 07:32:55 sure, all of it is possible Jan 06 07:33:15 so what do we do to start? Jan 06 07:33:33 the field would be helpful if we can propose that as a bitmap Jan 06 07:34:00 if somebody in us has some connection cards on Sprint or Verizon Jan 06 07:34:07 Start simple, make the basic voice work or something Jan 06 07:34:27 we can get one of those working then work on socs Jan 06 07:34:28 oh Jan 06 07:34:44 well that was the problem for me, I had no way to test voice Jan 06 07:34:54 voice calls are the same as gsm though Jan 06 07:35:39 So just take one interface, make it work, then another, etc Jan 06 07:36:10 Maybe we add CDMA-only interfaces, won't know until someone reads the spec and tries Jan 06 07:36:52 we don't have a spec, it disappeared with cdmatech.com docs year ago Jan 06 07:37:29 balrog-kun: what hardware then? Jan 06 07:37:37 sorry Jan 06 07:37:39 jho: Jan 06 07:37:42 JohnnyLo: Jan 06 07:38:32 what about http://www.3gpp2.org/Public_html/specs/index.cfm Jan 06 07:39:12 yes, pretty much everything is the same Jan 06 07:39:16 as 0707 Jan 06 07:39:23 atgen Jan 06 07:39:34 no sim, no reg, fake pdp Jan 06 07:39:38 voice is the same Jan 06 07:39:51 JohnnyLo: what hardware are you working on? Jan 06 07:43:14 qualcomm cdma board Jan 06 07:43:48 which? Jan 06 07:43:53 surf? Jan 06 07:44:06 6k 7k 8k Jan 06 07:45:40 7k Jan 06 07:46:56 or 8k Jan 06 07:52:03 ok Jan 06 07:52:22 so you're running linux/ofono on arm11/cortex? Jan 06 07:52:33 yes Jan 06 07:52:39 cool, that's my plan with htc touch pro 2 Jan 06 07:52:53 what amss line? Jan 06 07:53:50 i am not pretty sure Jan 06 07:54:41 is there any relationship between maemo and oFono? Jan 06 07:59:22 ask holtmann for clarification there Jan 06 08:01:54 11•12holtmann11• is there any relationship between maemo and oFono Jan 06 08:04:43 I saw that extensions for CDMA/EVDO are welcomed, wanna ask if there is any guildline for implement those extensions. Jan 06 08:06:23 I mean, will client apps specify which RAT(Radio Access Tech) they want to use? Or clients just use those services directly, ofono decides which RAT it is right now. Jan 06 08:11:04 doesn't it just enum radios? Jan 06 08:11:10 should it matter? Jan 06 08:14:54 but CDMA supposes to be different with GSM, from SPEC Jan 06 08:15:13 SPEC? Jan 06 08:15:19 I don't think enum radios are enough Jan 06 08:15:28 yes, but should it matter to ofonod client or to connman Jan 06 08:17:16 okay, my question is, for example, at command sets are different Jan 06 08:17:57 than GSM API may be suitable for GSM not CDMA Jan 06 08:17:57 some implementation should be modified Jan 06 08:18:41 if using the same API names Jan 06 08:19:22 mostly the same Jan 06 08:20:20 what about the difference? separate them with logistics in the same API? Jan 06 08:20:40 or out of API? Jan 06 08:23:06 I think a bitmap or struct per supported protocol Jan 06 08:23:15 as I have hybrid (7600a) Jan 06 08:23:31 and I need to support both Jan 06 08:23:59 the bitmap let's core call only supported features, no sim on cdma side for instance Jan 06 08:24:18 the driver can implement both correctly Jan 06 08:24:40 the problem is the statemachine or whatever since there's only on at interface Jan 06 08:24:53 I'm not quite sure how windows mobile handles this Jan 06 08:24:59 I have to do some logging Jan 06 08:26:11 okay , the bitmap is a good idea Jan 06 08:32:53 tmzt: actually, some functions need different state/logistic for gsm/cdma. For instance, call handling, there's no multi-party call in cdma, hence the logistic in core differs. Jan 06 08:35:02 if client app uses "org.ofono.VoiceCallManager.Dial" to make a voice call, ofono core needs to tell which RAT it is in use. otherwise, client app needs to use another interface ( ex: org.ofono.VoiceCallManager.Dial.cdma ). Jan 06 08:35:27 which approach is preferred in your idea? Jan 06 08:39:44 What is RAT? Jan 06 08:42:46 radio access tech, i think they are CDMA/UMTS/EVDO... Jan 06 08:43:19 And why should that be part of the Dialer API. Jan 06 08:43:51 The UI should not care about it at all. Users can't tell the difference anyway. They only care about the phone call. Jan 06 08:43:54 holtmann: my question is about hybrid chips with a single at interpreter Jan 06 08:44:06 where the different modes share state Jan 06 08:44:29 Actually the the ones I have seen so far, can only run either GSM or CDMA. Not both at the same time. Jan 06 08:44:55 this one can, at least it can see gsm networks while cdma is running Jan 06 08:45:02 and also access sim Jan 06 08:45:07 (phonebook) Jan 06 08:45:17 I will put some AT logs together Jan 06 08:45:20 tmzt: gsm/cdma may have different at commnads. BTW, the logistic may differs. Jan 06 08:45:41 We are still not exposing that level of detail in the D-Bus API. Jan 06 08:46:16 holtmann: so, apps don't have to worry about that. right? Jan 06 08:46:32 Stop making the same mistake over and over again. The D-Bus API is meant for simple UI applications. It doesn't need to know details about this level. We have to handle it inside oFono. Jan 06 08:46:40 ofonod should take care of those different parts, right? Jan 06 08:47:39 Yes. Jan 06 08:47:54 holtmann: agree, thanks. Jan 06 08:58:49 okay, anything you have on how multi protocol should work I would love to see Jan 06 08:59:10 and I will do what I can to help anyone working on multi or cdma Jan 06 08:59:21 but I can't test on hardware right now Jan 06 09:06:42 sure. but need to plan how it goes first. Jan 06 09:09:41 does 7600a support at commands like "clcc" in cdma mode? Jan 06 10:49:22 I'm connected right now, I can check I think if you tell me what to try Jan 06 21:16:44 holtmann: Any suggestions on assignment of persistent device ids to the modems? Jan 06 21:17:34 Actually yes. We have to use the identifier from the modem.conf again. That is as best as we get with static devices. Jan 06 21:17:44 For USB devices, I wanna use the serial number. Jan 06 21:18:05 Which should be the IMEI if proper implemented. Jan 06 21:18:54 What about SPI or phonet? Jan 06 21:19:36 phonet, I don't know, but it should have a MAC addr somewhere. Or maybe it can do a pre-step before registering the modem. So that should be fine. Jan 06 21:19:45 serial is usually fake/missing Jan 06 21:20:03 kernel can id pci attachment (by id in sysfs) Jan 06 21:20:10 Serial goes via modem.conf anyway. So it is configured by the system guy. Jan 06 21:20:17 which is usually quite static in netbook type design Jan 06 21:20:37 If serial number doesn't exists, then falling back to VID/PID combination seems fine. Jan 06 21:20:48 (holtmann) for usb devices I want to use the serial number Jan 06 21:20:56 that's the one I mean is missing Jan 06 21:21:05 is ofonod getting properties from udev? Jan 06 21:21:14 Depends on the devices. I have a lot of them where the serial numbers is the IMEI. Jan 06 21:21:16 can you use libudev for hal replacement soon? Jan 06 21:21:23 Yes. We are using libudev already. Jan 06 21:21:29 Way ahead of you ;) Jan 06 21:21:29 those are good firmwares, not socs Jan 06 21:21:34 cool Jan 06 21:21:46 As I said, fallback could be VID/PID. Jan 06 21:22:00 ok, so someone point me at some code that grabs device id / whatever Jan 06 21:22:18 if I wasn't so behind on kernel (or stuck with cdma devices which a perpetually behind) I would be ready to work on some of this Jan 06 21:22:29 plugins/udev.c Jan 06 21:22:37 but for devices I use a modem probe is best way to get serial Jan 06 21:22:42 cmi Jan 06 21:23:32 denkenz: You have to fix the core first to allow a unique id string when creating a modem (like we had before). Only if NULL fallback to something auto assignment like we do right now. Jan 06 21:23:51 So we can convert modemconf and use the section name as unique id. Jan 06 21:24:07 Then I can easily fix up the udev stuff. Jan 06 21:24:22 If you wanna get your hands dirty on the udev stuff, then go ahead. Jan 06 21:24:27 is there a salted name that has to work before probing the modem? Jan 06 21:24:54 I can't see any other way to make our socs work Jan 06 21:25:10 there's no path or device name, but thankfully only ever one modem Jan 06 21:25:14 holtmann: Naming the modems is trivial Jan 06 21:25:27 holtmann: But I don't know what udev_get_ function to use Jan 06 21:26:12 It is inside the udev property list. Jan 06 21:26:23 I can fix that for you. Jan 06 21:26:36 tmzt: The D-Bus object path for the modem has to be fixed before probing. Jan 06 21:26:58 ugh, ok Jan 06 21:27:02 And it has to be unique. Otherwise other tools like ConnMan go crazy. Since ConnMan will keep the Powered state for you. Jan 06 21:27:08 well, smd0 works fine for me Jan 06 21:27:33 since that's the AT channels kernel tty device Jan 06 21:27:39 it's unique enough Jan 06 21:27:41 For embedded devices a modemconf style configuration with fixed values works of course. Jan 06 21:27:47 But we are also running on the desktop. Jan 06 21:27:54 would rather do udev though Jan 06 21:27:57 I know Jan 06 21:28:21 I would like to keep our images generic accross g1 aNd touch pro etc. Jan 06 21:28:32 holtmann: So something like udev_device_get_property_value, what's the property name Jan 06 21:28:34 ? Jan 06 21:28:37 we can detect hardware type with udev rule Jan 06 21:28:52 It is possible to get this fixed if you are really into it. Jan 06 21:29:31 Takes a bit more work. And eventually kernel fixes with DEVTYPE to figure out what TTYs are actually doing. Same as I did for networking devices. Jan 06 21:30:11 From 2.6.33 and forward we get DEVTYPE={wlan,wwan,bluetooth,wimax,...} classifications from the kernel for networking interfaces. Jan 06 21:30:16 what's DEVTYPE ? Jan 06 21:30:38 I just mean hardcoding driver in modems.conf won't work Jan 06 21:30:38 Part of the uevent send from the kernel. Jan 06 21:30:57 SCSI uses for the difference between partitions and disks. Jan 06 21:30:57 since we have different modem firmware on different devices we want to support with one image Jan 06 21:31:29 radio core is not quite wwan Jan 06 21:31:37 that doesn't map, it's also voice Jan 06 21:31:48 and some of our networking is ppp, some rmnet Jan 06 21:32:32 Remember. That is for the network interface. We have to do something _similar_ for TTY. Not exactly the same names of course. Jan 06 21:32:46 Don't mix things up here. Jan 06 21:33:41 The idea is that we can tell from userspace what the device is for. Not wild guessing or probing. Since normally the kernel already knows that in the first place. Jan 06 21:40:13 okay, I'm saying that it's not a device where netdev defines modem Jan 06 21:40:24 I misunderstood the sgn.ificance of devtype then Jan 06 21:44:10 I do wanna do the same for TTY, but that area is a bit more crappy. I hate the TTY layer. Anybody opting for sockets or simple character devices is my friend. Jan 06 21:45:12 smd has builtin flipbuffer semantics Jan 06 21:45:18 smd_tty Jan 06 21:45:27 it would make little sense to remove tty Jan 06 21:46:13 Fair enough for these, but other hardware designs have busses that doesn't require any of it. It is just a data pipe. Jan 06 21:46:34 sure Jan 06 21:46:43 but I'm not getting the point Jan 06 21:46:56 all my devices have one AT channel, the broken htc stuff Jan 06 21:47:15 newer devices are even more broken and report a bunch of stuff as ascii Jan 06 21:47:20 Really bad luck on your side then. Jan 06 21:47:41 the name is fixed (/dev/smd0) it's a tty Jan 06 21:48:16 as long as I can put that in udev rules but configure the driver used in ofono based on a sysfs entry I'm good Jan 06 21:48:37 yeah, but driver will have to deal with that Jan 06 21:48:44 the g1 driver is a start Jan 06 21:52:12 holtmann: persistent naming pushed Jan 06 21:52:23 Feel free to fixup udev Jan 06 21:54:24 You do have to run a proper check on the path. Only a-z, A-Z, 0-9 and _ are allowed. Jan 06 21:54:34 Otherwise libdbus will abort ofonod. Jan 06 21:54:47 I do Jan 06 21:54:49 And since these values might come from malicious devices. Jan 06 21:55:08 __ofono_dbus_valid_object_path Jan 06 21:55:10 Yes, you do. Sorry. My bad. I overlooked that. Jan 06 21:56:26 I rely on dbus for duplicates checking Jan 06 21:56:50 ofono_modem_register won't work on non-unique ones Jan 06 21:59:37 Do we get a proper error code if one already exists. Jan 06 22:00:22 you get EIO Jan 06 22:01:08 We can tweak this, but I didn't want to do linear search on the modem list Jan 06 22:01:24 Theoretically we can catch this during modem_create, but then a hashtable is required Jan 06 22:01:36 how long is the list? Jan 06 22:01:42 likely to be Jan 06 22:01:48 handling corners here? Jan 06 22:01:55 as many modems as you have, small in practice Jan 06 22:02:40 Trying to avoid it actually, duplicate paths can't be registered on DBus Jan 06 22:03:38 holtmann: I'm also removing powered persistence tracking from my todo, I'm assuming it is connman's bug now Jan 06 22:04:06 ConnMan is already doing that. Assuming that the object path is persistent. Jan 06 22:04:23 nod Jan 06 22:05:24 ofono won't work at all without connman then? Jan 06 22:06:03 It will. Your network system has to just enable the modem at some point. Like someone has to bring up your Ethernet or WiFi device. Jan 06 22:06:30 only when the context is up? Jan 06 22:06:37 it's voice only otherwise Jan 06 22:06:44 Not following. Jan 06 22:06:58 why does connman care about a voice modem Jan 06 22:07:13 and what does powered mean in this context Jan 06 22:07:30 It cares about the modem in general. Same as for GPS etc. Someone has to take about flight mode. Jan 06 22:07:46 We even power on/off Bluetooth even if not used for PAN. Jan 06 22:08:06 my modem only has an ip if the gprs/3g/evdo context is up Jan 06 22:08:19 it's ppp, but there's also rmnet version Jan 06 22:08:24 that's not modem power Jan 06 22:08:34 You are missing the big picture here. Jan 06 22:08:45 yeah, I'm confused. this is to use connman ui clients for flight mode? Jan 06 22:09:03 If you don't wanna use ConnMan, that is fine, but then you have to have a system that stores persistent power states. Jan 06 22:09:26 what does that mean? this cfun state or something else? Jan 06 22:09:33 There will be always some sort of system. We are just using ConnMan for this. Even if it is a voice only device. Jan 06 22:09:49 Modem property Powered=true/false. Jan 06 22:09:55 bhow can modem driver handle that and powersaving without tracking powered state at all Jan 06 22:10:22 so a downstream client monitors the state (persistence) but the modem driver plugin and ofonod manages it? Jan 06 22:10:38 the dbus call to change powered still goes through ofonod? Jan 06 22:10:42 power saving is different. That is up to the modem or its driver. We are talking about simple modem on/off states. Jan 06 22:10:52 Yes. ConnMan talks D-Bus to ofonod. Jan 06 22:10:58 right, but they are handled somewhat the same Jan 06 22:11:06 sorry to confuse that issue Jan 06 22:11:08 tmzt: You're thinking too much ;) Jan 06 22:11:19 That is just CFUN overloaded by the AT command spec. Jan 06 22:11:28 if no calls cfun should be in powersave, the battery life is significant here Jan 06 22:11:35 savings is Jan 06 22:11:36 right Jan 06 22:12:05 And btw. it is up to the driver to map it to CFUN. ConnMan just changes the Powered property. Jan 06 22:12:08 so I want to use a simple daemon for two features before adding connman, which requires reacrhitecting ui frontend Jan 06 22:12:12 Anyway, ofono handles powered state and power management, obviously Jan 06 22:12:14 yes Jan 06 22:12:19 ok Jan 06 22:12:38 connman just manages user preferences and stores them Jan 06 22:12:40 driver knows when there's no calls so pm is automatic Jan 06 22:12:43 So if we're in flight mode and shut down, when we restart we should still be in flight mode Jan 06 22:12:45 reguardless of powered Jan 06 22:12:49 yes Jan 06 22:12:56 that type of persistant Jan 06 22:12:58 okay Jan 06 22:13:12 It is just not persistent over reboots. You have to do that by yourself. Jan 06 22:13:45 it works on windows mobile and why should be doing the same (we merpbhone) Jan 06 22:13:52 we Jan 06 22:14:27 You can do that of course. Either you use ConnMan for that. Or you write you own manager that handles persistent storage. Jan 06 22:14:28 okay, the daemon has two jobs, emergency calls when a button is held but diabled for testing Jan 06 22:14:46 and switching voice path when a voice call is made in ofono Jan 06 22:15:00 and answering call when ringing and green button (evdev) is pushed Jan 06 22:15:23 adding powered state to this cli daemon is trivial with a /var entry Jan 06 22:15:55 so four jobs now, nothing major Jan 06 22:24:53 denkenz: Pushed the udev serial patch. Jan 06 22:25:09 I am using the short serial number for now. We can use the long one if it causes problems. Jan 06 22:25:35 It is not falling back to VID/PID yet. However I wanna see how far we get here before doing that. Jan 06 22:25:43 And the full serial number would do that for us anyway. Jan 06 22:27:52 sounds good to me Jan 06 22:46:19 denkenz: We do have something similar for the primary context object path, too. Jan 06 22:47:25 eh? Jan 06 22:48:18 They are all named primarycontext1 etc. So if you try to match them up, then it becomes a problem. Jan 06 22:48:42 We do have to store values like auto-connect and others based on a per context. Jan 06 22:49:06 actually that one might be persistent Jan 06 22:49:58 let me check Jan 06 22:50:13 Except during remove / re-add and restarts. Jan 06 22:52:01 So we store the contexts by an id inside the settings file Jan 06 22:52:25 when we load it, we re-enumerate them Jan 06 22:52:31 We could simply preserve the id and set the next_context_id to the highest one Jan 06 22:53:41 or we could store it as primarycontext_%s, name or something Jan 06 22:57:21 Just keep the storage as it is. And just make sure we set next_context_id to the highest value. Jan 06 22:57:55 Then it is unique and persistent. Then we can change it later if something else makes more sense. Jan 06 23:00:49 ok, the only trouble there is we can potentially overflow int32 Jan 06 23:02:24 This is one of the reasons I re-enumerate them Jan 06 23:04:50 Yeah. If that happens we can do gap checking. Jan 06 23:05:14 You have to call the D-Bus API a lot of times first. Jan 06 23:06:01 Hello Jan 06 23:06:17 Also in case of remove you could just decrease the next_id if possible. Jan 06 23:06:38 That still leaves potential gaps, but mitigates the risks a bit. Jan 06 23:07:05 Alternative is to change the D-Bus call to take some type of identifier. The Name should be UTF-8 human description. Jan 06 23:08:12 Let's do "object CreateContext(string identifier, string type)". And have Name property changeable via D-Bus SetProperty. Jan 06 23:26:13 yeah my thoughts as well Jan 06 23:26:46 But I'd hate to do uniqueness checking Jan 06 23:27:25 Perhaps we simply allocate a bitmap and cap the thing at 256 max contexts or something? **** ENDING LOGGING AT Thu Jan 07 02:59:56 2010