Software

[Da_Blitz]

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

[Ferret-Simpson]

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.

[Da_Blitz]

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

[koen]

have a look at eds-dbus before trying to reinvent the wheel.

[Da_Blitz]

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

[lardman]

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

[koen]

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]

That would be [a href=\"http://www.linuxtogo.org/gowiki/EflPlatformDesign]http://www.linuxtogo.org/gowiki/EflPlatformDesign[/url]

[Ferret-Simpson]

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.

[handheld-linux]

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

[Ferret-Simpson]

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.

[wsuetholz]

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

[Ferret-Simpson]

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.)

[wsuetholz]

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

[Ferret-Simpson]

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

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.

[adf]

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

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?