[Bitpim-devel] Another developer added to the fold

[Chris Cleeland]

Hi,

I just found this software yesterday, and am already excited. I just
recently purchased two Sanyo 8100s (one for myself, one for my wife) and was
disappointed to learn that the futuredial software only supported phonesync.
Bah! Then this appeared!

This software has amazing potential, so I look forward to working on it to
get it to run more effectively not only on the 8100, but also on various
platforms: Linux on my laptop, OS X on my wife's home machine, Win98 on my
wife's work machine.

I'd also like a way to sync/combine calendars, and fetch call logs in order
to help in reconciling billing with clients.

Warning, though: I know jack about python, so there will likely be some
newbie questions regarding that. I am, however, no software novice, being
proficient in C, C++, Java, perl, etc., and having designed and implemented
many large-scale systems in the past & present.

Thanks so much, Roger, for sharing this software with us!
-cj

[Steven Palm]

Post by Chris Cleeland
This software has amazing potential, so I look forward to working on it to
get it to run more effectively not only on the 8100, but also on various
platforms: Linux on my laptop, OS X on my wife's home machine, Win98 on my
wife's work machine.

I'm the newly appointed Mac geek here. ;-)

I'm working on getting some of the Mac specific things up to speed,
such as USB cable support, comm port detection, application bundling,
etc... Glad to have you on board with such enthusiasm, and looking
forward to the future direction of the project. BTW: I just started
using Python for this project as well, but it's pretty straight forward
from everything I've run into so far.

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Jim]

Python Rocks!

Books I found useful when I first started:

- Learning Python, Lutz/Ascher, OReilly, ISBN 1-56592-464-9
- Programming Python, Lutz, OReilly, ISBN 0-596-00085-5
- Text Processing in Python, Mertz, Addison-Wesley, ISBN 0-321-11254-7
- Python Cookbook, Printed and Online

For wxPython see wxWindows doc set and the demo code.

I too will be lending my skills to the furthering development of this wicked
cool app. Roger's got quite the TO-DO list that I will be chipping away at.

Jim West
www.jameswest.com

The box said Windows 95 or better, so I installed Linux.


---------- Original Message -----------
From: Steven Palm <***@n9yty.com>
To: bitpim-***@lists.sourceforge.net
Sent: Tue, 16 Dec 2003 11:35:54 -0600
Subject: Re: [Bitpim-devel] Another developer added to the fold

Post by Steven Palm

Post by Chris Cleeland
This software has amazing potential, so I look forward to working on it to
get it to run more effectively not only on the 8100, but also on various
platforms: Linux on my laptop, OS X on my wife's home machine, Win98 on my
wife's work machine.

I'm the newly appointed Mac geek here. ;-)
I'm working on getting some of the Mac specific things up to speed,
such as USB cable support, comm port detection, application
bundling, etc... Glad to have you on board with such enthusiasm, and
looking forward to the future direction of the project. BTW: I just
started using Python for this project as well, but it's pretty
straight forward from everything I've run into so far.
-. ----. -.-- - -.--
-. ----. -.-- - -.--
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bitpim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

------- End of Original Message -------

[Stephen Wood]

On Tue, 2003-12-16 at 11:49, Chris Cleeland wrote:
...

Post by Chris Cleeland
This software has amazing potential, so I look forward to working on it to
get it to run more effectively not only on the 8100, but also on various
platforms: Linux on my laptop, OS X on my wife's home machine, Win98 on my
wife's work machine.
I'd also like a way to sync/combine calendars, and fetch call logs in order
to help in reconciling billing with clients.

...

Great!

I added the support the Sanyo 8100. I actually only have a 4900, but it
seems that the 4900 and 8100 are pretty similar (except for the camera
of course!) Have you tried BitPim on your phone yet? Have you written
to the phone? (I have a report of a 8100 owner reading the phonebook,
but have not heard if anyone has tried writing to the phone. It should
work.)

I was going to work on improving general calendar support, but just
havn't time. There is probably a lot of fun work there with syncing
calendars and reading/writing iCalendar/vCalendar files.

I can easily add fetching of the call logs into the BitPim calendar.
Roger: Can you suggest a syntax for call history calendar entries so
that the savecalendar routines for the various phones can know not to
try to write these call logs into phone event calendars? Perhaps a
calendar entry type flag with possible values like
event
call_alarm
missed_call
outgoing_call
incoming_call
message

Steve

[Roger Binns]

Post by Stephen Wood
I can easily add fetching of the call logs into the BitPim calendar.
Roger: Can you suggest a syntax for call history calendar entries so
that the savecalendar routines for the various phones can know not to
try to write these call logs into phone event calendars? Perhaps a
calendar entry type flag with possible values like
event
call_alarm
missed_call
outgoing_call
incoming_call
message

I think I would rather keep the call history seperate from the
actual calendar. (It too can also be displayed in a seperate
calendar display, just not the main one). I don't think it
would be useful for BitPim to write back out to the call history.

One thing I was thinking of doing is injecting SMS messages
into your email. The user can then use their standard email
filtering to keep a log etc. The headers can even be suitably
frigged so you can just hit reply etc.

The same can be done for the call history.

Any thoughts?

Roger

[Stephen Wood]

Post by Roger Binns
I think I would rather keep the call history seperate from the
actual calendar. (It too can also be displayed in a seperate
calendar display, just not the main one). I don't think it
would be useful for BitPim to write back out to the call history.

Yes, I don't see much value for writing a call history back to the
phone.

What about Call Alarms. On my phone, I have 15 slots for these. They
are similar to events, except that they hold a phone number and a
date/time. They are meant to remind you to call someone. I recently
tentatively added reading and writing of these to the sanyo code. On
writing, if a calendar entry description looks like a phone number, I
send it to the Call Alarm list instead of the event list on the phone.

Post by Roger Binns
One thing I was thinking of doing is injecting SMS messages
into your email. The user can then use their standard email
filtering to keep a log etc. The headers can even be suitably
frigged so you can just hit reply etc.

It looks like Python has classes to handle various mailbox styles!

Post by Roger Binns
The same can be done for the call history.

I would like call history to be exportable from BitPim in whatever ways
Calendar information is so that call histories can be imported in to
other calendars.

I'll add some code for reading the call history and SMS messages, but I
won't try to do anything with the information yet.

Steve

[Chris Cleeland]

Post by Roger Binns

Post by Stephen Wood
I can easily add fetching of the call logs into the BitPim calendar.
Roger: Can you suggest a syntax for call history calendar entries so
that the savecalendar routines for the various phones can know not to
try to write these call logs into phone event calendars? Perhaps a
calendar entry type flag with possible values like
event
call_alarm
missed_call
outgoing_call
incoming_call
message

I think I would rather keep the call history seperate from the
actual calendar. (It too can also be displayed in a seperate
calendar display, just not the main one). I don't think it
would be useful for BitPim to write back out to the call history.

Writing out to call history probably isn't useful. However, from a user's
perspective (not from an implementation perspective), I'd like to be able to
view call log data from within the calendar view.

Post by Roger Binns
One thing I was thinking of doing is injecting SMS messages
into your email. The user can then use their standard email
filtering to keep a log etc. The headers can even be suitably
frigged so you can just hit reply etc.
The same can be done for the call history.
Any thoughts?

Interesting, but requires extra services for Sprint phones (i.e., PCS
Vision). While it's cool, it's not worth $10-15 /month more to me, so I'm
looking to avoid using it. If data is available, I'd rather see it come
through the serial port.

-cj

[Roger Binns]

Post by Chris Cleeland
Interesting, but requires extra services for Sprint phones (i.e., PCS
Vision). While it's cool, it's not worth $10-15 /month more to me, so I'm
looking to avoid using it. If data is available, I'd rather see it come
through the serial port.

It would come through the serial port. The general gist would be that
if you told BitPim to import your SMS and/or call history, they would
show up in your email client with appropriate date, to, from, subject
and bodies. You can then do whatever filtering you want in your email
client for putting stuff in folders.

Roger

[Stephen Wood]

... The general gist would be that
if you told BitPim to import your SMS and/or call history, they would
show up in your email client with appropriate date, to, from, subject
and bodies. You can then do whatever filtering you want in your email
client for putting stuff in folders.

I don't quite understand how we would really make call history fit in
email. It would work if there was a database to translate nubmers into
email addresses and an editor popped up that let you type in a subject
and notes about each call, but that sounds like too much work for
developers and users.

Steve

[Chris Cleeland]

Post by Stephen Wood

... The general gist would be that
if you told BitPim to import your SMS and/or call history, they would
show up in your email client with appropriate date, to, from, subject
and bodies. You can then do whatever filtering you want in your email
client for putting stuff in folders.

I don't quite understand how we would really make call history fit in
email. It would work if there was a database to translate nubmers into
email addresses and an editor popped up that let you type in a subject
and notes about each call, but that sounds like too much work for
developers and users.

Hi, Steve,

If you want to branch CVS and commit some of the sanyo 8100 stuff you're
working on so I can test it, let me know the branch tag and I'll pull it over
and take a whack.

In general, is there any kind of ChangeLog or anything on the project so that
it's easy to track aggregate changes?

[Stephen Wood]

lopers and users.

Post by Chris Cleeland
Hi, Steve,
If you want to branch CVS and commit some of the sanyo 8100 stuff you're
working on so I can test it, let me know the branch tag and I'll pull it over
and take a whack.

I don't need to branch anything. I'll add some code to read the call
history and leave it disabled with an if statement or something. There
are some data words included in the call history packets that I don't
understand, so it would be good to have more eyes look at protocol logs.

Make sure you try out your phone with the current CVS version. The
Sanyo specific code has not had much testing beyond myself.

Post by Chris Cleeland
In general, is there any kind of ChangeLog or anything on the project so that
it's easy to track aggregate changes?

You can see changes on individual files with the viewcvs. The code for
the Sanyo 4900/8100 is in the files com_sanyo4900.py, com_sanyo.py, and
p_sanyo.p.

[Roger Binns]

Post by Stephen Wood
You can see changes on individual files with the viewcvs. The code for
the Sanyo 4900/8100 is in the files com_sanyo4900.py, com_sanyo.py, and
p_sanyo.p.

BTW it is really easy to make a seperate module for the 8100 and share
all code, with any exceptions you want to make. I did it for the
VX6000 and VX4400. Here is how:

com_sanyo4900:
======
class Phone(...):

protocolclass=p_sanyo4900
desc="Sanyo 4900"

def calendar(self):
# whereever you need protocol objects, instantiate them like this
req=self.protocolclass.calendarentry()
======

p_sanyo8100:
======
%{
# This brings all objects from sanyo4900 into this namespace
from p_sanyo4900 import *
%}

# you can put any overrides here, eg if the calendarentry is
# a different size

PACKET calendarentry:
99 STRING description
======

com_sanyo8100:
======
class Phone(com_sanyo4900.Phone):

protocolclass=p_sanyo8100
desc="Sanyo 8100"
def __init__(self):
com_sanyo4900.Phone.__init__(self)
=======

The above will let you have seperate files for the phones, but share
all the code except whatever you decide to override. It also means
the user will see the correct phone model in any log messages.

Roger

[Chris Cleeland]

Okay, forgive the python ignorance...

Post by Roger Binns

Post by Stephen Wood
You can see changes on individual files with the viewcvs. The code for
the Sanyo 4900/8100 is in the files com_sanyo4900.py, com_sanyo.py, and
p_sanyo.p.

BTW it is really easy to make a seperate module for the 8100 and share
all code, with any exceptions you want to make. I did it for the
======
protocolclass=p_sanyo4900
desc="Sanyo 4900"
# whereever you need protocol objects, instantiate them like this
req=self.protocolclass.calendarentry()
======
======
%{
# This brings all objects from sanyo4900 into this namespace
from p_sanyo4900 import *
%}
# you can put any overrides here, eg if the calendarentry is
# a different size
99 STRING description
======

At this point, there's only one protocol file for sanyo; are you suggesting
that it should be broken up, or just offering this as a suggestion?

Post by Roger Binns
======
protocolclass=p_sanyo8100
desc="Sanyo 8100"
com_sanyo4900.Phone.__init__(self)
=======

There's another class declared at the end of this file: class Profile. Does
that need to be inherited, too? Or, does it need to be broken out into a
separate class, or perhaps phonebook.py needs to be massaged to allow
individual phones to decorate a phone book entry?

[Stephen Wood]

Post by Roger Binns
BTW it is really easy to make a seperate module for the 8100 and share
all code, with any exceptions you want to make. I did it for the

I will create a module for the 8100 in the next few days. While I
believe that the 8100 interface is identical to the 4900 in those
matters that have been put into BitPim, it is time to do it. And who
knows, we may somehow figure out how to download camera pictures from
the 8100, and since the 4900 doesn't have a camera, that's a
difference. I will also make a module for the Sanyo SCP-5300 since I
also believe that is similar.

What I will do is move most of the code from com_sanyo4900.py into
com_sanyo.py, and then create mostly empty com and protocol files for
the three phones.

Steve

[Chris Cleeland]

Post by Stephen Wood
What I will do is move most of the code from com_sanyo4900.py into
com_sanyo.py, and then create mostly empty com and protocol files for
the three phones.

That sounds like a good plan. What about the Profile class that's in there?

Should there also be separate protocol specs for each phone, similar to
what's being done for the communications?

[Roger Binns]

Post by Chris Cleeland
At this point, there's only one protocol file for sanyo; are you suggesting
that it should be broken up, or just offering this as a suggestion?

The email was mostly directed at Stephen who would know exactly what to
do :-)

Roger

[Roger Binns]

Post by Stephen Wood
I don't quite understand how we would really make call history fit in
email. It would work if there was a database to translate nubmers into
email addresses

You mean like the phonebook :-)

Ok. here are some examples. Imagine your name is John Smith and number
is 123 456 7890

For SMS it is easy. Incoming message:

======
From: ***@vtext.com
To: ***@vtext.com
Date: Jan 1 2003
Subject: Lunch # from SMS message

body body body # from SMS message
======

An outgoing message would be the same except the contents of the From
and To would be the other way round.

Here is what an ordinary call would look like, assuming the number
had been phone in your phonebook

======
From: 555555555 (Mary Brown)
To: John Smith
Date: Jan 1 2003, 10:43am
Subject: Phone call: 25 minutes # could also be Missed Call, Outgoing call etc

The same information in the body
======

The SMS case is very nice and easy but you already have things you can
turn into email addresses, and you have something you can make subjects
and bodies out of.

The call history certainly is of less utility. If you already use a
time tracking and annotation tool that hooks into your mailer, then
having the call history in there too is great. If you don't then how
do you track your email history?

We will certainly have to be very careful exporting it to any calendar
destination that is also a calendar source for BitPim.

Roger

[Stephen Wood]

Post by Roger Binns
For SMS it is easy.

Of course.

...

Post by Roger Binns
Here is what an ordinary call would look like, assuming the number
had been phone in your phonebook
======
From: 555555555 (Mary Brown)
To: John Smith
Date: Jan 1 2003, 10:43am
Subject: Phone call: 25 minutes # could also be Missed Call, Outgoing call etc
The same information in the body
======

I still think call history makes more sense going into a/the calendar,
but putting it in email has possibilities. If the phone number is in
the phonebook and there is an email address for that name, the email
address can be used as the "From". Also, if the phone number was a
mobile, we could generate an SMS address. (Is there a SMS gateway where
you can send to ***@something.com without having to do something
different for different carriers).

Steve

[Roger Binns]

Post by Stephen Wood
(Is there a SMS gateway where
different for different carriers).

Of course not! That would allow people to move easily amongst
carriers :-)

Roger

[Chris Cleeland]

Post by Stephen Wood
I added the support the Sanyo 8100. I actually only have a 4900, but it
seems that the 4900 and 8100 are pretty similar (except for the camera
of course!) Have you tried BitPim on your phone yet?

Yes. I have gotten exceptions, and am not yet versed enough in python or the
structure of bitpim to understand what or why. Most particularly, it seems
that it doesn't like to read into some of the nvm part of the

Post by Stephen Wood
Have you written to the phone? (I have a report of a 8100 owner reading
the phonebook, but have not heard if anyone has tried writing to the phone.
It should work.)

No, I haven't yet.

Post by Stephen Wood
I was going to work on improving general calendar support, but just
havn't time. There is probably a lot of fun work there with syncing
calendars and reading/writing iCalendar/vCalendar files.

Yes! That's what I want. Ultimately, I'd like for my wife and I to be able
to sync our two calendars so that we can keep up with each others' schedules
more easily.

[Steven Palm]

Post by Stephen Wood
I was going to work on improving general calendar support, but just
havn't time. There is probably a lot of fun work there with syncing
calendars and reading/writing iCalendar/vCalendar files.

That would be cool to sync up with Apple's iCal application! :-)

I'm going to take a look at a stub to integrate or at least
import/export from Apple's system Address Book application.

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Chris Cleeland]

Post by Steven Palm

Post by Stephen Wood
I was going to work on improving general calendar support, but just
havn't time. There is probably a lot of fun work there with syncing
calendars and reading/writing iCalendar/vCalendar files.

That would be cool to sync up with Apple's iCal application! :-)

Yes!

Post by Steven Palm
I'm going to take a look at a stub to integrate or at least
import/export from Apple's system Address Book application.

You would then rock :-)