Re: Keypad for fingers, not stylus
Tommi Virtanen wrote: On Wed, Oct 10, 2007 at 08:57:22AM +0200, Openmoko wrote: So far I've only implemented the very basics, e.g. to write a c three pushed on one butten is required. I've also plans for implementing a dictionary, e.g. T-9 or an alternative: the most common words appear based on the already entered letters (if ba entered manually by pressing a sequence such as (22,22,2) then the phone should propose for example banana). Do remember that T9 is patented, you'll need to make it different enought that it isn't derived from T9. I'd suggest starting with fresh ideas. And also if you are making a dictionary system it would be great if it was standalone rather than integrated in to your own specific input system. That way every other input system that is written can use it with little effort (and more importantly without writing their own). Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Plea to developers: Make data for all applications available to scripting languages
Giles Jones wrote: On 15 Sep 2007, at 22:53, J F wrote: What I would like to see is ALL programs having a way of getting at their data from a scripting language. I don't know if it makes sense to have some guidelines for developers to make it easier for this information to be got at. This would be for someone more competent than me to suggest. Quite simply, if long term storage utilises and embedded database then so long as the scripting language can access it then it will be fine. Only if the database supports concurrent access by multiple processes, which most don't. You'd be better off supporting a single standard API to obtain the obvious data such as contacts/calendar/todos (EDS being the one that I believe that the developers have settled on). Which leads to a question: is there some way to extend the information held for each EDS entity so that calendar entries contacts and the like can have additional (arbitrary) fields? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: application idea
John Locke wrote: Jim McDonald wrote: Possibly more interesting would be for the calendar app to look ahead at your position-to-be and provide you with details (or even alerts) of what (for example) the weather is likely to be when you get to where you are going. Knowing that it will probably be raining when you step off a 'plane allows you to pack appropriately. Wow that would be some hardware... a time-warping GPS module, to know your location before you get there! Think of the possibilities: Show my position, today + 7 days... All it would take would be a well-formed location field for each calendar event, not exactly magic... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: application idea
Jeff Andros wrote: Last night, while I was looking at the monsoon blowing just outside the heat-island... in my open-top jeep... I had an application idea: GPS based weather feeds. on a schedule/when you move into a new area, the phone will go out to a server and retrieve the weather information for the area you're in. [...] Possibly more interesting would be for the calendar app to look ahead at your position-to-be and provide you with details (or even alerts) of what (for example) the weather is likely to be when you get to where you are going. Knowing that it will probably be raining when you step off a 'plane allows you to pack appropriately. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ATI to provide specs
Harald Welte wrote: [...] Which part exactly are you missing? That there are no docs now? Well, there is no GTA02 hardware being shipped now either! And if the community rather wants us to finish the documentation first, and then write the driver: Please let us know. Do you really prefer to get a device that does not have any working driver at all, but with a thousand-page manual (rather than the other way around: first have FOSS Drivers, and then get the docs as soon as our incredibly small team finds time to do so)? Not wishing to be contrary for its own sake, but my answer to your (supposedly rhetorical) question would be 'the docs'. If we had a complete manual then that would be enough for other people to write the driver, whereas if we have a driver and no docs then it's going to be next to impossible for the community to add features or fix bugs in said driver and we're stuck with whatever functionality your incredibly small team finds time to implement. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: mailing list management
hank williams wrote: Oops. As usual I hit reply to and it went to casey personally Its broken. Just so that the 'silent majority' don't lose out on this one, I would like to point out that there are approximately 1,500 people subscribed to this list. Can we assume that unless we hear from them their vote is 'no change'? There are pros and cons to each system, but anyone who has already set up their own filters will have done so on the existing system so I suggest we leave it as it is. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko future.
Rod Whitby wrote: Visti Andresen wrote: Sébastien Lorquet [EMAIL PROTECTED] wrote: (This is a suite to laforge's message on gsmd-devel) I'm a little disappointed about laforge's message :( Targetting geeks only will never help to make OpenMoko known. They are planning to sell it to your mom and dad: http://openmoko.com/about-02-roadmap.html So unless they are geeks Therein lies the continual struggle between marketing and engineering ;-) Ah yes. That said, with a project like this that is very engineering-driven and with engineering being very vocal about what they see as the limits of the project it would be useful to hear a (re)confirmation of the marketing vision to make sure that it is still valid. Sean? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko future.
Sean Moss-Pultz wrote: I don't see our statements as conflicting. Harald is our lead system level architect. His job is to focus on his task at hand and deliver a stable, high performance system. He's trying to give the geeks what they want first. Which is great, the concern was around the forward-looking statements that there was no interest in a market beyond the niche of people who want an open-source 'phone. Why it was a concern is below... [...] We want to build _the_ best open mobile device in the world. 100% open. Only when we reach this point will our strengths be appreciated by the mainstream user. I understand the thinking here, but the mainstream user will neither know nor care about open source. If a 'phone is available that fixes a lot of the existing hideousness within UIs, if a 'phone is available that allows people to do what they want with it, if a 'phone is available that allows them to make calls at the best prices without suffering the whims of the network operators, *that* is when it will be appreciated by the mainstream user. Of course that I understand that open source is the way that openmoko is going to use to enable these things, and also that without a solid foundation it won't be possible to do so, but there needs to be some focus on getting there rather than just having a cool 'phone. And although we wouldn't expect to sit back for someone else to make this a reality we would hope for support where required. Mark my words, we will make an end user mobile device of which this world has never seen before. Now that is something that I think we can all agree on. And many thanks for the response, it has renewed my enthusiasm in the project (along with finally getting the *!* build system to build and include my binaries in the image :)). -Sean Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
Kero van Gelder wrote: [...] I'll think about the extension concept a bit more. The fact that you chose a scenario to modify a phone number is interesting. How about calling a person from a Contact? and then choosing VoIP or GSM by those extensions? (specifically, I do not think gsmd is the place where the call should originate, in the image you have on the Wiki). The reason why I chose the gsmd in the example is because it is the final action prior to actually making the call and as such it is a good place to make changes that you don't want seen by the higher levels. For example, say you wanted to call +1-555-123-4567 but the calling card extension decided that the number that you actually need to dial is +1-800-800-8001,555-123-4567 you do not want the latter number showing up in the journal, last call lists, etc. That said, I agree that you would probably want to put another (similar) extension method in to the dialer. If you had such a method in the dialer then it could tell the dialer to initiate VoIP rather than GSM, in which case the GSM extension method would never be called as you wouldn't go down that codepath. The more extension calls we have the more flexibility we have, although there is a balance between having them everywhere with no-one knowing to which one they should attach their extension and having them in very few places thus limiting the ability to extend the base product. In terms of bindings, what I really need to do is put together the D-Bus methods to register/unregister an extension and for the extension handler to call the extensions dynamically. At that stage you'll be able to integrate your Ruby code very easily. I'll give it a crack over the next couple of days and see what I can put together. Watch this space, as they say... Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
Kero van Gelder wrote: Something I thought of, the application (or whatever) that might want to register an extension need not be started yet. After all, DBus is capable of starting applications (and I'm sure Contacts, Agenda and a few more will be in the nearby future). Yep I'm planning on adding in service files when I get hold of a real 'phone to work with. So at least for choosing VoIP or GSM, the system-dbus must tell what's available and Contacts must tell how we can reach the person at all. I think *calling* Contacts is more suitable than letting it register an extension, for this case. What do you think? Not sure, it may be that there is a 'routing' extension that takes information about what call to make and works out the method to send it with. Of course, a lot of this type of functionality is being built in to the core applications so it will take some untangling. I think that until there is at least a skeleton set of applications in place it will be hard to work out the linkages from one item to another and how it all hangs together. The example above is a case in point, where handing off the call information from the dialer to the gsmd (or wherever) is not something that I had originally envisaged would be part of the extensions framework but it could be if the rest of the pieces are coded in a suitable fashion. Definitely a wait-and-see. [...] Same here, polished my code, you can now use it like in the two little attachments. It's not as clean as Ruby can be, yet, but it's rather close now. I'm also happy to have freedesktop.* in a separate file, now. I bet I can ext_handler = DBus.proxy.new(org.openmoko.ef.eh.Gsmd, /org/openmoko/ef/eh/Gsmd/, org.openmoko.ef.eh.Gsmd) ext_handler.call(method, sig, arg0, arg1, ...) already :) Not any more you can't :) So thanks to a long flight I had a chance to tidy up the code and put some registration methods in place. I also renamed some of the interfaces and paths because it looks like I'm ending up with a single process for both registration and handling of specific calls. The latest code is at http://www.devzero.net/openmoko/dist/omext.tar.gz I have also updated the Wiki at http://wiki.openmoko.org/wiki/Wishlist:Extension_Framework The key difference is that you can now register your own extension by sending a method call org.openmoko.ExtensionHandler.Register(). Details of the parameters are up on the Wiki. Note that registrations are persistent so once you have registered you will remain so unless you send an org.openmoko.ExtensionHandler.Unregister() with the same parameters as you used to register. This also means that extensions can be written in any language (for example, Ruby :)) and do not need any information hard-coded in to the extension handler itself. At current I'm using gconf as a backend so if you do want to see the results of your registration attempts you can do so by running 'gconftool-2 -R /extensions'. Have a play and let me know how it goes. Still lots to do but it's starting to take some shape. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Henryk Plötz wrote: Don't worry too much about that right now. I don't know what the current plan for this problem is but, given that OpenMoko already uses dbus, I'm quite sure that it will include dbus. Going from I have an application that, when a call comes in, pops up a dialog and asks the user to accept or reject the call to I have an application that, when a call comes in, broadcasts a dbus message 'There's a call from ..., anyone want to handle that?' and waits for a reply ... 'Anyone? Anyone? Ok, openmoko-dialer, your turn'. is easy. Only if it isn't already hard-coded to go to the dialer in the first place, which is why I'm bringing this up now. Adding dbus support is *not* the hard part, that's getting calls working at all (and of course all the nifty things you'd want to plug in, but those are outside of the scope of the base infrastructure). I agree that adding D-Bus support is not in itself difficult, but trying to put the 'right' system in place is not trivial. You cannot broadcast a D-Bus method so you need some sort of mediator in the middle (you could broacast a signal but that's fire-and-forget so you then have no idea if anyone is even considering replying). As such you need a central arbitrator to handle this functionality. I've been playing with some code locally in the last few days to get my head around this idea, and will write up a few use cases on the Wiki so that everyone can see where this is heading. I understand and agree that making/receiving calls is the most important thing right now for the core team but I and no doubt most of the rest of the people outside of the core team can't help much there, so if there is a way of them being able to build extensions to the will-be functionality without getting in the core team's way it should help all round. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Hans L wrote: Hey folks, Great discussion going on here. I've been putting a lot of thought into the issue too, so I figured I'd add my two cents. [...] Yep this is very similar to what I'm thinking of. Given that we're all pretty close to what we think we need it's probably time to put something on the Wiki. I've put an initial page at http://wiki.openmoko.org/wiki/Wishlist:Extension_Framework so if people can make any additions that they wish there it would be easier to track and get us to the stage where we can get the buy-in of the openmoko team and start laying down some code. There are a few things that you mentioned here that I haven't yet covered in the Wiki such as profiles, use of the configuration GUI and the like so if you want to flesh them out on that page it would be much appreciated. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Henry Law wrote: What about using a system similar to iptables? Each module only provide function to match against some call info. Some target actions are defined by the notification system. And rules is setup by user so that when a call event come in, the notification system can check the call info against the rules one by one until one is match and do the target action in that rule. Normally each target action will do their jobs and then terminate the matching process. Yep that's pretty much what I'm talking about here. But to do this we will need the low-level code to send us the methods/signals so that we can take the appropriate actions, which is the bit that I'm worried is not being considered and so this type of functionality will just not be possible without being a 'core' developer. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jeff Andros wrote: ok, but here's the thing with having full plugin framework: what if two plugins take mutually exclusive actions (I.E. one plugin has a whitelist, it tries to answer the phone because it's the girlfriend, but the other plugin attempts to send the call to voicemail because your gps says you're in a movie theatre) who should win? I think we need to take one step beyond independent plugins: This could be handled through either ordering or priority, either would work. There still needs to be a control center that receives the basic message from the core code (e.g. incoming call), works out which modules are interested in the message and then sends it on to them. If you are using ordering then you would probably chain the messages so that if the message was altered by one module the altered message would be received by the next/./ If you were using priority then you could send the message to every module at the same time and wait for all responses before continuing. Ordering would probably be easier both to develop and for end users to manage. Priorities *may* by faster, although that's not guaranteed by any stretch. The best solution would probably be a combination of ordering and priorities. As you mention, although this would be a very useful system a lot of the ability of it to be end-user friendly would rely on a very intuitive GUI (or alternatively a system that is restricted in such a way that a configuation GUI is not required). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Giles Jones wrote: I don't think the project will last long if there's too much snobbery about who does what. In this case it isn't snobbery so much as ensuring that there is a simple way to put the right functionality in the right place. Overloading gsmd with lots of (potentially conflicting) user requirements would lead to code that was hard to maintain and with a steep learning curve, hence the point that only those who put the time and effort in to understand all of the wrinkles would be able to make safe changes, and these people would be 'core' developers purely because that's where they would have to do the development to get the functionality they required. 'core' isn't a synonym for 'better' here, it just refers to developers that work on the core functionality of the product rather than the (in my opinion) more interesting stuff of the higher-level applications. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Giles Jones wrote: Jim McDonald [EMAIL PROTECTED] wrote : This is why you send the event to the notification system and then wait for the response. The notification system would read the users rules and act appropriately. For an incoming call if you had a rule which says you are busy then the process would be as such: 1.Phone process receives incoming call event. 2.Phone process sends call details and incoming call event to notification system. 3.Notification system checks user settings. Agree up until now, but this is the bit where we diverge; I believe that if done properly there could be any number of responses to the fact that there is an incoming call, and they won't all fit happily in to a simplistic event code model. Let's pick a simple example mentioned earlier on the list, where the 'phone is set to reject all calls but if someone calls three times in five minutes then you want to make the 'phone ring because it may be urgent. Now, the really important bit here is not the technical details of how it accomplishes the requirement but the fact that it is highly questionable if you want to put this type of functionality within your base 'phone. It being just one of no doubt 100 esoteric features that end users will come up with you don't want to be faced with a massive set of options or a slow 'phone because it's checking so many things every time someone calls you. You want this to be a much more flexible system, and to do that you need to think of the 'notification' system as a central messaging hub where it can pass on the fact that there is an incoming call, along with the details of that call, to any module that may want to do something with it. The other key thing to realise here is that each of these modules will be a nice and simple beast that understands its own job and neither knows nor cares about what is going on elsewhere in the system. Writing a piece of code that will carry out the above function is simple, but if it was to be inserted in to gsmd (or the notification system) then it would be a much bigger task as you need to understand how the existing system works, where your code fits, write something, send it in as a patch, get it reviewed, and finally in the next major release of the software it will show up. (Also bear in mind that incoming calls are a very simple example as there is not much that I can think of doing with them off-hand. However, if you start to think about outgoing calls there are many more things that you may want to do, including allowing/not allowing the call (for child or business 'phones), routing the call through another system (calling cards), sending/not sending your caller ID with the call, allowing/not allowing calls to call anyone not in your address book, only allowing non-business calls outside of business hours, who knows? The point is that every time we build a static code path we're limiting the ability of the next person to do something we didn't think of, which makes the whole thing less free than we would like. I'd again say to look to the Firefox extensions system as a good example of where this has worked well, and not only gives people lots more freedom in how they surf the web but has made the browser far more powerful (and successful) that it could have been with any single set of developers while at the same time making it easy for outside developers to add to the product with minimal, if any, knowledge of the existing codebase. I think that is the model that openmoko should be trying to emulate, otherwise we'll just end up with an open source 'phone with all of the inflexibility of a closed source 'phone (to the majority of people that might use it), and that doesn't seem to be a great leap forward from where things are today. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
[EMAIL PROTECTED] wrote: OK, first time you mentioned Firefox, I thought you meant browser and/or GUI stuff. But you focus on extensions/plugins :) Sorry yep was thinking of the design philosophy rather than the specifics. If I look at my own install I have four of five extensions (out of a few thousand) that I use and their cumulative impact is to make Firefox far more useful *to me* than any other browser out there on the market. Any place where you can hook in little snippets of code will do. I think I'll play with a few modules I can see interact here (addressbook, agenda, IM client (mostly its away settings); I'll mock them for starters) and how to aggregate the decisions from those modules on what to do with an incoming call/SMS/... I will use dbus, but that says nothing about the actual format/info sent over that bus. I'll be off-line over the weekend, but with some luck, I'll have a bit of code (i.e. showing format/info) to show Sun or Mon. Yep I think I'll see if I can grab some time over the weekend to put together some words and diagrams explaining what I'm thinking about and how it would fit in to the general 'phone framework. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hooks in Base Code
[This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, /etc. /The point that I'm trying to make is that there are a multitude of things that you /could/ do but each person will have a limited number of things that they want the 'phone to /actually/ do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Daniel Robinson wrote: I don't know how much of the at signaling is available at the data terminal. What is the signaling for sending caller ID to a cellular phone? For example, on POTS, the digits are signaled with a Bell 103 modem between the first and second ring. Someone said something about having the ringback tone be a sound file that is configurable according to caller. I don't know if that is possible from the phone. The ring back tone is generated by switching equipment, not the terminal. To clarify, I'm thinking not of getting in the way of the basics of things like gsmd, which should handle the fact that there is an incoming call and also pick up the caller ID if present, but what openmoko does as a result of this information. Given the fact that there is an incoming call from number 555-123-4567 what should the 'phone do? Should it silently ignore the call, send it straight to voicemail (either operator or on the 'phone itself), use a specific ringtone for the user, even shut down entirely (some sort of if I ring my 'phone from this number then nuke it option!). The point is, there are lots of possibilities and we don't want them all sitting inside gsmd, it makes more sense for them to be external modules that can be chained together in a clean fashion without requiring direct access to something as sensitive as gsmd. At least, that's my take on it. --Dan Cheers, Jim. On 7/18/07, *Jim McDonald* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: [This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, /etc. /The point that I'm trying to make is that there are a multitude of things that you /could/ do but each person will have a limited number of things that they want the 'phone to /actually/ do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Anton Afanasyev wrote: I am not entirely sure if I'm thinking straight, but here's my take on customizing functionality of the OpenMoko: say, when a call comes in, the appropriate module detects that, gets the caller ID if possible, maybe other info (such as the contact info associated with it, if any), and then theres a few things that happen: there could be a config file somewhere that defines a number of 'pre-processing' libraries for the call (or maybe jsut allow one such library), which exports certain functions, such as IncomingCall([some call info here]). Well, OpenMoko would call those functions, and the library(ies) would output some result, such as RejectCall, SendToVoiceMail, PlayAutomaticAnswer, etc. Basically, what I am getting at is that instead of changing the whole OS/kernel to support these functions, it would be possible to write a simple library, and then those libraries would process calls, GPS location changes, etc. Yep that's roughly what I'm talking about but we need the base code to be set up such that it will make those calls and pay attention to the results, which is the main thrust of my argument. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Doug Jones wrote: Take a look at EToys. [...] That's certainly a style of GUI that could be applied to the hooks if required, although at current I'm more concerned about the ability for the hooks to exist than the specifics of how they would be configured. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom wrote: The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. But not at all transparent to the end user. Again assuming that there is some sort of key caching going on, what is the real consumer benefit to having multiple ways of categorising data to different levels of security versus having a simple protect my data against unauthorised access checkbox somewhere that blanket-enables encryption? (Alternatively there could be some way in which these configuration settings are pluggable and people with the more complex requirements could download the advanced settings plugin and leave normal users with a simple yes/no choice.) --Tim Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom wrote: [Encryption options] Yep I understand that there are lots of possibilities and options, I just think that if something ships by default it should provide end users with a very simple dialog that is basically an on/off switch for 'protection of personal data' (or something else that doesn't even mention encryption) and the additional levels of configuration can be made available through plugins or whatever. Perhaps I've spent too long battling with ugly interfaces, but I think that if OpenMoko is going to have a broader audience than the people on this list and their kindred-in-geekness then a large amount of the effort will be deciding how to keep the interface as simple and streamlined as possible rather than loading the default build with every option imaginable... --Tim Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Jonathon Suggs wrote: One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. I'd caveat that with comment that one of the biggest bugbears against the FOSS camp is usability so if this type of thing is going to be implemented then it should be a single system-wide option that gets handled away in the backend so that applications don't even need to know about it and that users don't have to pick and choose (or worse, select on a per-application basis) what data is encrypted. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joe Pfeiffer wrote: [Encrypting data] We certainly want a global scheme -- but I think we do want a per-data-item granularity. I've certainly got things on my phone whose protection I don't care about (shopping lists) and other things that have legal implications (notes on how various students' class presentations went). I want to be able to choose save this encrypted vs. save this, and then when I access data I've encrypted I have to enter the password. Yep but on the flipside if you have some data that you want encrypted then encrypting all of it won't do any harm (perhaps a slightly slower response time, and assuming some sort of key caching going on the occasional entering of a decryption token, perhaps on unlock and 'phone startup?). Having to choose for each piece of data if it is encrypted or not, and having to handle that in every application individually, is a great example of where choice can be too much. I think that having a single system-wide setting and handling it appropriately (and far enough down the stack so that applications don't have to worry about it) would provide a simple and uniform approach to this problem without continually asking the user to decide which data is to be encrypted and which not. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Clare Johnstone wrote: On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare True, but that's just another choice to be made when storing the data plus of course you have filesystem folders, arbitrary categorisation through tags, automatic classification depending on the type of data etc. so there are lots of concepts that can be used, and each one is a potential set of confusion (I tagged the data as 'sensitive' but the system didn't encrypt it because I accidentally put it in the 'public' folder). I just think that this is a good example where having an all-or-nothing approach is preferable to fine-grained control, as the benefits are minimal compared to the complexity for development and day-to-day effort for end-users that have to use such a system. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joel Newkirk wrote: Tobias Gruetzmacher wrote: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. Or perhaps some sort of voice recognition, perhaps a user-chosen phrase? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: DBus for Generic Data Access Methods?
Marcel Holtmann wrote: [...] Okay so there has been a fair amount of discussion here but I think we've veered off track a bit. To try to re-phrase my thoughts: - Current DBus object paths are application-centric (this is by choice of the application) - Without a well-known set of paths it is hard new applications, especially small modular ones, to work easily as they don't know where to plug in to the rest of the system (this is broadly equivalent to having sketchy information on an API) - There seem to be two options (ignoring the uninteresting ones): - take a combination of the existing application-centric paths and make it available somewhere as a reference guide - create a new set of paths which form an OpenMoko standard and are adhered to by all (friendly) apps that run on OpenMoko I would hope that most people would agree with the first two points, in which case the question is which of the two options in the third point makes more sense. I believe that the second option is the right way to go because it allows us to build a logical framework rather than an application-centric one and that allows far more flexibility both initially and down the line. It does mean that someone needs to create and manage that framework, but that could be a community effort and not particularly taxing, at least for a first cut. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: DBus for Generic Data Access Methods?
Marcel Holtmann wrote: [...] the question is still why. We have EDS. So no reason to invent another interface for the same purpose. Don't try to over-complicate things. So this is an argument against abstraction, which I understand but disagree with. It comes back to the two choices that I gave a couple of emails back: work with the existing APIs or attempt to create a new one that is specifically designed for OpenMoko's purpose. You prefer the former, I prefer the latter. Let's leave it there for now and see what the overall community thinks when it gets closer to the time for this type of thing to be decided upon. Marcel Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
