OESF Portables Forum
Everything Else => Distros, Development, and Model Specific Forums => Archived Forums => PocketPenguin => Topic started by: Da_Blitz on July 28, 2006, 12:33:36 am
-
Startting this up so we can have a list of software that needs to be developed (user space)
Suggestions:
Mobile phone control: A dialer applicatoin that can do notification, perhaps bassed off d-bus
Address book: so we can cross refrence and call people from the adress book
SMS handler: there are many exsisting apps that do dilivery via the unix mail system, perhaps utilize that
-
The notification system will have to be running all-the-time, so that when the RPU wakes the CPU, the CPU can handle the notification and Address-book.
I think Mail-System integratration is a good idea for both SMS and MMS, because alot of Modern phones can handle email aswell (Although few are actually CONFIGURED to.)
It looks to me like what is basically required is a complete new combined Communications and Address-book suite for Linux Smartphones, because alot of the existing packages are basically modifications to old stuff that is sort of patched together.
I'll put together a couple of designs for it, and post them on Ferret-Simpson.co.uk (And link here) when they're done. . .
Because remember, in a Smartphone all of these things have to work together:
Addressbook and CallerID,
Phone,
Mail,
SMS/MMS,
VideoPhone,
Voice OIP,
Video OIP and Instant Messaging,
And of course Synchronisaton of contacts, Message histories, emails. . . . all through the same method as standard PIM.
So I don't think it's as necessary to have a bunch of individual programs, but an interconnected set of programs that work together, like on a normal Mobile phone, or to a certain extent (Because it ain't perfect) on a windows Smartphone.
To get Linux phones like the PPZ to be popular, they have to do things, but not only do they have to do them, they have to do them BETTER than a normal phone would.
Applications we could look at to use as a base and modify, or a source of inspiration?
Thunderbird (Email), KPIM (For the addressbook and VOIP), Gommunicator (SMS and Phone code), GAIM (One of the best Messenger suites on Linux PDA's), aMSN (Currently has working MSN webcam code aswell as support for all the latest Messenger protocols).
I'm not suggesting it's easy, just that it's required. I'll do my best to help.
EDIT: Again, this will be a good help for the OpenEmbedded HTC and HP phone ports. . . They're still lacking a good phone application suite.
-
mm, i might have to add some of this to the Universix page on the wiki, it is somthing i should definattly think about
the address book should be a data format (im thinking XML) and a set of libries to minipulate the data so that any program can use it, not so much a program (remeber i will be running this from the command line and would like to get the same feature set as the GUI programs)
the mail system is THE way to do it in my opinion. it works well for everything but i suspect we may need a hack or two to make the mail service understand mobile phone numbers and send it in the correct manner.
the work around at the moment is to send the mail to the user SMS on the local system and make the first line the mobile number you want the message to go to, this is nice but thier is no facillity to have it cross refrence the adress book, we almost need to build our own mail system that can take advatage of other ways to deliver mail and other data
microsoft did it well in Windows mobile, there is one interface for handeleing mail and SMS/MMS
caller ID is a tricky one as the notificiation con be diffrent depending on the enviroment (console, OPIE, GPE, other (eg raw X)) so i think the phone "server" should be heavily dependent on D-BUS for its notification,
eg the phoned (phone daemon) sends a "call" event that is picked up by the current users phone call notification system, this notification system then uses the adress libaries to cross refrence the users phone book and pops up a box saying someones calling, i dont belive that the phoned should be responsible formaking sound or turning on the rumble, it should be the users phone notificatoin program that does this as it makes it easier to configure and is multi user friendly, in the case of no one logged in then we will have to have phoned do the notification.
i dont think they have to do things better, many things win even if they are not the best solution. what it has to do is do it in a familliar way, only we are covering both basses in my opinion. if they can send an email in thunderbird and then recive and reply to an SMS using the same interface then we have done it
that said things will need modification to do it properly, we can ethier bend to them or have them bend to us, with open source this is much less of an issue scince we have the source so we can write tha patch meaning less bending (as usual straght to the point)
i think D-bus is a technolagy we will have to embrace for notification, it does its job well. up till now i dont think that D-Bus has had a killer app but this really fits that catagorey. sure its widly used but i think this is the type of thing where people would look at it and go WOw that was a better idea than using pipes for notification
-
have a look at eds-dbus before trying to reinvent the wheel.
-
mmm seems like a good idea, i only see it used for importing contacts but i assume its used for all types of signalling it does have its flaws if we use it, only one mail program supports feeding in sms messages in this way where as all email programs accept email
as i said it needs some thiniking but its a step in the right direction
perhaps we need a d-bus bassed mail delivery system
-
What about the GPE PIM suite - these are actively developed.
It might also be worth asking mickeyl what he's thinking about for his Linux smartphone by way of software (he's adding/added it to OE as a target).
Si
-
What about the GPE PIM suite - these are actively developed.
It might also be worth asking mickeyl what he's thinking about for his Linux smartphone by way of software (he's adding/added it to OE as a target).
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=136731\")
That would be [a href=\"http://www.linuxtogo.org/gowiki/EflPlatformDesign]http://www.linuxtogo.org/gowiki/EflPlatformDesign[/url]
-
Well, that's another good base source. XD
But my point is, having 8 individual tools is bloody useless if they don't actually know how to TALK to each other. So as well as our PhoneDaemon, we'll need to modify our Email program and Addressbook program to talk to each other, so that you can add a contact to your address book from within the email or SMS they sent to you. Same fo r Addressbook to phone links, so the Addressbook can start the Phone Dialler and connect, as well as store incoming caller numbers (From the phone call log).
The basic end result is that we should be able to access any program in our suite, from any OTHER program in our suite, without stopping, loading, reloading, copy-and-paste, and all the other hassle. Full automation and integration.
-
have a look at eds-dbus before trying to reinvent the wheel.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136728\"][{POST_SNAPBACK}][/a][/div]
I would even suggest to not invent anything new and focus on an open Hardware. We will be happy to sell it.
Use Linux, OpenBSD, Familiar, GPE, Qt, OpenZaurus, QuantumSTEP, ... whatever already exists. That is already open enough. The issue for most of these projects is the availability of Open Hardware!
Just make a nice "BIOS"-API to select which system to boot next time - if there are multiple kernels in memory (or memory card).
-- Nikolaus
-
The Secure Bootloader should be able to boot anything from AmigaROS to Linux to the HURD. Details have yet to be finalised, but it's a pretty sweet bit of software.
The OS isn't what we're worried about. Any OS will let this work as a PDA, our big challenge is putting together a set of Suites and Standards for the Phone userlevel software for it.
-
I'd like to try to help on the software side of things. Not much kernel work done, not much GUI stuff done either. Mostly I've been doing behind the scenes daemons.
I probably won't be able to get the hardware for a while I have no budget for things like this. But I've seen an ARM emulator, and I'm sure that the development stuff for the Zaurus would help. I have started playing with the openembedded stuff for my home multimedia setup.
Bill
-
We like Daemons.
There'll need to be one to handle traffic from the (As yet unresolved) phone system, Don't know what else needs one. . . It's OSH, so the documents will be around, and for the Phone Daemon at least, you'll have quiete a few willing betatesters. (I.E. Everyone who DOES have a device.)
-
I would think that there is no reason to wait for hardware to do the combined phone/email/sms/voicemail/... application. It could probably be designed and tested using a Zaurus with Bluetooth and WiFi connected to an outside phone.
Bill
-
Well, it looks like there'll be a modification to the actually Behind-The-Scenes Mail system. . (Sendmail server?) Which again looks to be yourr kind of thing. XP
As far as actual AT command structure etc goes, Gommunicator would be a good Code Base, at least for X and GPE. It's a Phone Answer/Call program, with SMS support.
http://www.handhelds.org/moin/moin.cgi/Gomunicator (http://www.handhelds.org/moin/moin.cgi/Gomunicator)
That's the page.
GPE would be a better system to start working in I think, because the code for the Phone program is alot more mature than the Qtopia port, and a Fully Opie port is non-existent. Also, Several people seem to like my choice of Thunderbird, so that would be a good base to look at integrating with say. . a new Mail subsytem or subsystem modification to handle SMS, MMS and Email.
As for a testing platfrom. . The AudioVox, Ambiccom, Chi Mei (Mine), and Japanese Vodafone cards all seem to have Phones (Although the 3g Voda. . Not sure) and are tested under Linux on the Zaurus (I use mine regularly for GPRS, and have used it via minicom as an emergency phone.)
If it works on one, it should work on the other with little or no modification. The PDA OS base isn't near finalised yet, but I'm going to assume it'll be an OpenEmbedded variant of Some kind, so the latest OZ/GPE should work ok as a dev, test platform.
-
Well, it looks like there'll be a modification to the actually Behind-The-Scenes Mail system. . (Sendmail server?) Which again looks to be yourr kind of thing. XP
As far as actual AT command structure etc goes, Gommunicator would be a good Code Base, at least for X and GPE. It's a Phone Answer/Call program, with SMS support.
http://www.handhelds.org/moin/moin.cgi/Gomunicator (http://www.handhelds.org/moin/moin.cgi/Gomunicator)
That's the page.
GPE would be a better system to start working in I think, because the code for the Phone program is alot more mature than the Qtopia port, and a Fully Opie port is non-existent. Also, Several people seem to like my choice of Thunderbird, so that would be a good base to look at integrating with say. . a new Mail subsytem or subsystem modification to handle SMS, MMS and Email.
As for a testing platfrom. . The AudioVox, Ambiccom, Chi Mei (Mine), and Japanese Vodafone cards all seem to have Phones (Although the 3g Voda. . Not sure) and are tested under Linux on the Zaurus (I use mine regularly for GPRS, and have used it via minicom as an emergency phone.)
If it works on one, it should work on the other with little or no modification. The PDA OS base isn't near finalised yet, but I'm going to assume it'll be an OpenEmbedded variant of Some kind, so the latest OZ/GPE should work ok as a dev, test platform.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136791\"][{POST_SNAPBACK}][/a][/div]
have you considerd evolution rather than t-bird? if the thing can run t-bird nicely, evolution should work too, and last I checked evolution was setup for more groupware sytems than t-bird. might be more versatile?
-
Last time I ran evolution it was a dog, and very buggy. I have found thunderbird to be very responsive and fairly stable, it's also nice to have the exact same email and browser on windows and linux, since I switch back and forth alot. Evolution doesn't run on windows afaik. OTOH, evolution is highly integrated with a PIM as well.
regarding the backend mail daemons, I haven't done much with sendmail recently, I'm currently using exim for my mailservers..
Do you really think that the MTA needs to be customized, or just the rewriting rules?
Bill
-
Last time I ran evolution it was a dog, and very buggy. I have found thunderbird to be very responsive and fairly stable, it's also nice to have the exact same email and browser on windows and linux, since I switch back and forth alot. Evolution doesn't run on windows afaik. OTOH, evolution is highly integrated with a PIM as well.
regarding the backend mail daemons, I haven't done much with sendmail recently, I'm currently using exim for my mailservers..
Do you really think that the MTA needs to be customized, or just the rewriting rules?
Bill
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136799\"][{POST_SNAPBACK}][/a][/div]
Right, hadn't used it in a while, forgot the pim thing. I was mostly interested in the ability to work with novell groupwise. One can always use a web browser, though.
-
Like I said: "Look into eds-dbus before reinventing the wheel", so please try actually looking into it. All your comments above cite problems that eds-dbus has solved. In case you didn't know: eds-dbus is being used on the nokia 770 as the contacts (and soon mail) *back*end. You can have a thin gui layer on top of that (tinymail, modest, dates, contacts).
-
Link me! WHOO!
XD
Is there a current Zaurus port?
-
Link me! WHOO!
http://projects.o-hand.com/ (http://projects.o-hand.com/)
Is there a current Zaurus port?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136829\"][{POST_SNAPBACK}][/a][/div]
I don't know what you mean with a 'zaurus port', but it is present in OpenEmbedded.
-
Yeah, OpenEmbedded counts.
Hmmm, that does look pretty useful. And of course, it's designed to go with it's own PIM and Mail suite. . .
Only thing we'd need to consider then is interaction with the Phone systems. I don't think that would be a big challenge. Our most important coding project then looks to be the Phone Daemon, and companion frontend software.
We'll need to sort out Ringtones as well.
MP3, OGG, WAV, MIDI
Any other formats people would like?
-
We'll need to sort out Ringtones as well.
MP3, OGG, WAV, MIDI
Any other formats people would like?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136838\"][{POST_SNAPBACK}][/a][/div]
Just hook it into gstreamer and you can use any format you'd like, and the plugin tree is a no-brainer with playbin and spider
-
Sweet.
Hol, do you think you could handle porting the Jack Daemon to ARM?
Blitz isn't sure but I think it's a good way to handle Audio Routing on the PPZ. . .
I can paypal you the price of a pint?
-
Hol, do you think you could handle porting the Jack Daemon to ARM?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136842\"][{POST_SNAPBACK}][/a][/div]
Is jackd really necessary? when making phonecalls you don't need low-latency since the latency produced by the phone system and physical distance will be much larger than the latency produced by alsa.
-
Aye, it's just really easy to rerouute data on the fly with it.
Also, since the Sound chip we're using is likely to be quite good, and we're also likely to have SPDIF, I and at least 2 others have mentioned using it for recording purposes.
For UNIX music studio work, it doesn't come much better that Jack as a backend. I use it on my Recording PC. . .
-
Also, can I make a software note of XINE? It's my favourite X-based video program. Either that or a good frontend for mplayer. . ? (Is XINE an mplayer F/E?)
-
Also, can I make a software note of XINE? It's my favourite X-based video program. Either that or a good frontend for mplayer. . ? (Is XINE an mplayer F/E?)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136846\"][{POST_SNAPBACK}][/a][/div]
I'd rather use gstreamer, since nokia is paying those dudes to optimize it for ARM
-
But will it have optimisations for our Hardware Codecs?
-
But will it have optimisations for our Hardware Codecs?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=136851\")
You can code them. And if you are serious about power consumption have a look at ASoC: [a href=\"http://www.rpsys.net/openzaurus/patches/alsa/info.html]http://www.rpsys.net/openzaurus/patches/alsa/info.html[/url]
-
Hmmm. . . When the iMX is supported, then that looks like a useful addition. . .
more things. . .?
CF drivers for our 54G wireless chip. Currently, only USB drivers are available. How will the accelerometer and Scroll wheel interface with say. . . SDL?
We're also going to have to come up with some modifications to the videoforlinux stuff. . . I think we shoud already have drivers for the camera, but how we link it to the Videophone, Camera Application (Is there one for GPE?) and to our Video-over-IP. On which note. . . aMSN port?
-
I would think that there is no reason to wait for hardware to do the combined phone/email/sms/voicemail/... application. It could probably be designed and tested using a Zaurus with Bluetooth and WiFi connected to an outside phone.
exactlly why i started the topic, any work done will help out the other lin phone projects
mmm, the discussion about t-bird and evolution is a bit off topic, i was thinking more about infrastructure here. if we use evolutions D-bus then only eveolution gets the upgrade which is bad
i was hoping to talk about the problems we will encounter and how to work around them (SMS bieng one example, how to send and recive)
QEMU can do arm system emulation, perhaps we should look into hacking that
the CF cards are just serial ports with a gsm modem on the other end
i really like Daemons , thats why i belive all phone dialing should be carried out by a deamon hanging off d-bus, this also means that we have less contention issues over more than one program trying to read/write the same device and also allows programs to ploo the state of the line,
so for example ask if we can hang up the data connection and make a quick call, then have the Daemon auto reconnect and notify the program using the data link that connection has been reestablished
-
No option to have the both running simultaneously?
NOTE:
The GPRS/GSM cards are starting to get thin on the ground. They're about £120 each, at current price.
Expansys.com and expansys-USA.com both ddid them at my last check. If you want to get one, you'd better get one quick, Audiovox have stopped thier OEM of the card (Audiovox and the rest all OEM the parts from an unknown 3rd party)
-
Another note that I forgot about. . I do this alot.
I'm going to agree with DB on the Evolution side.
unless the EBS-Dbus becomes the base for a new set of PIM for Opie, and another for Qt aswell, then we'd be better replacing it, or modifying it to give it a more universal interface that the other existing software can access with simple modification.
I will however admit that I do like it, it seems like a good system. It's not perfect for what we want, by ANY means, even for just under the GPE system. . . But it does look like the best CET to apply to the job.
-
well part of the reason i said tha about eds d-bus is because im a vt100 fan so doing it properly (email bassed) makes sense, also makes backing up your sms a brezze
if you are talking about too things at once in refrence to the low level programs then have you ever tried to have 2 programs talk to a /dev file at onec, even if one just writes and the other reads. it caused me a debugging nightmare with a 68hc11 and db11, once i worked it out i almost kicked myself for bieng so stupid
-
I was talking more about multiplexing, so that you could run both a GSM phone call, and an Internet connection over GPRS/3G, simultaneously.
-
oh right, thier was just too many things to multiplex in my second last post, can you do that with 3G, i hate phones to begin with so i am not familliar with 3g except for the data speeds and the insane prices
-
I'm pretty sure you can. . . My HTC Universal Smartphone-PDA runs Windows Mobile 5, and has 3G support. I'll hook myself up to skype on it, make a GSM call, and see if I get disconnected. (You'll have to wait till I get it, in about 5 weeks.)
On the note of voicemail, we should make sure that the program has support for redirecting to a "Traditional" voicemail, as well as the onboard PPZ voicemail. With PPZ-OVM, the quality should be improved over traditional VoiceMail, but Traditional voicemail could be more reliable, in case of a Flash-Card burnout. . . or FAT error. . Or other data-killing HDD error.
-
I'm pretty sure you can. . . My HTC Universal Smartphone-PDA runs Windows Mobile 5, and has 3G support. I'll hook myself up to skype on it, make a GSM call, and see if I get disconnected. (You'll have to wait till I get it, in about 5 weeks.)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137016\"][{POST_SNAPBACK}][/a][/div]
It depends on the network. In some part of the country I can do gprs + gsm, in other parts gprs stays connected but no bits flow and in the rest gprs gets plain disconnected.
-
I guess it'll be a case of implementing it, and from then it'll be down to how lucky you are.
-
i belive mgetty would be the best option for that, then i could have voice mail on my phone and recvie faxes
mmm that is intresting about the gprs stuff bieng country specific (and perhaps carrier specific as well) i guess the notification thing might have to come with carrier specific tweak files (i see this as bieng a good thing in general for all programs)
-
Here is an ARM emulation package that mentions the Freescale chips...
Softgun (http://softgun.sourceforge.net/)
Softgun on Gentoo Linux (http://gentoo-wiki.com/HOWTO_Softgun_ARM_Emulator)
Bill
-
That looks useful. Only ARM9/21 though. And doesn't look like the fastest emulator ever. . . 2.2% efficiency. . .
-
Would this project... Telepathy (http://telepathy.freedesktop.org/wiki/) be of any use?
The Telepathy project aims to provide a unified framework for all forms of real time conversations, including instant messaging, IRC, voice calls and video calls. It uses the DBus messaging system to provide a simple interface for client applications, allowing them to quickly benefit from Telepathy's functionality.
At the core of Telepathy is the DBus interface specification which describes how Telepathy components communicate with each other. We are up to spec version 0.13. For a more approachable introduction to the structure of the framework, try the System Overview document. The Ubuntu spec for SIP/IM integration includes a good rationale for this distributed approach.
-
http://telepathy.freedesktop.org/wiki/ (http://telepathy.freedesktop.org/wiki/)
Where on EARTH did you find that? You are a genius and I love you! Et Hemm. . .
That, is EXACTLY what We need. A united VOIP, Messenger, and Phone system. Only problem is, it doesn't look like the phone part has been built yet. . .
Hmm, I'm not sure whether "Phone" Actually means GSM and UMTS Video. . Or whether it refers to VOIP phone. Still, being open source, that doesn't mean we couldn't ADD them. . .
-
Actually I saw it in a linux magazine I was browsing the other day. Unfortunately I can't remember the magazine and had forgotten about the software until this morning!
-
Well it's genius, this is the software I was talking about in either this or the older thread. Not this individual project, I didn't know it existed, but this concept. Genius!
-
actually i have been looking into zeroconf with gaim, did you know that on a properly set up system gaim will provide contacts for everyone using zeroconf on the network.
now if you hook this up to wifi and the PP it would be great althgh they do mention that it likes low latency
that telpethy thing sounds good, i will look into latter and see how it fits in with everything, i was just thinking of using somthing overblown like asterix. but if this does what i think it does it should be a light weight solution to our problems
-
Well, I have a feeling it's not going to be something that will work out of the box, we WILL have to do a little coding ourselves. . maybe incorporate a version of Gomunicator into it???
And there's still the question of SMS/MMS/Email/Direct-Push-Mail. . . That one is going to need to be thought out VERY carefully.
-
came up with a solution to sms and perhaps mms at the least
keep using the email system however have a deamon (user sms) that watches its mail box using inotify, when it recives a message from you (mail sms) it fowards the body contents onto the recipent or recipents in the subject line
when the sms program recives a sms it sends a message with the subject [sms] <number> for mms then the extra files can be added as attachments
makes it easy to filter to a mail box, only problem is if you have a footer for your mail or gpg sign it, however perhaps you can find a way to disable it on a per email basis (or for local accounts) or build the ability to strip that into the sms client (not nice but it works )
i belive it solves the problem very nicly, ok its not the best solution but it will wrok with all email clients that exsist, means you have to do the copy and paste by hand however some advantages is you can make the sms client do number lookup against say abook for example or ldap, so you get a message with the subject [SMS} +6120432234234 (Sue bing)
works nicly with the deamen because the reply adress would be the demon on the local machine (always nice)however even if your client adds RE: to the front its trivial for the sms program to work out which number to send the message to
a wierd side effect is if you have a server with a phon attached and running software like this then you could send a message to the machine to the sms account (eg for my domain sms a)pocketnix.org (dosent work)) and have that message sent via sms, be great if you had a server in your home country whie you are away, instant sms portal
comments?
-
smstool from stefan frings is a great program for sending and receiving sms on a gsm phone, and it it very easy to write an email to sms gateway using it, and wouldn't be too hard to monitor the incoming spool and turn sms's into emails.