bitpim-devel — For bitpim developers

Re: [Bitpim-devel] Another developer added to the fold

[Roger B. <ro...@ro...>]

> 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: 555...@vt...
To: 123...@vt...
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

Re: [Bitpim-devel] Another developer added to the fold

[Stephen W. <sa...@us...>]

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

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

Re: [Bitpim-devel] Another developer added to the fold

[Chris C. <cle...@oc...>]

On Tue, 16 Dec 2003, Stephen Wood wrote:

> On Tue, 2003-12-16 at 17:03, Roger Binns wrote:
> 
> > ...  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?

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
      Support Me Supporting Cancer Survivors in Ride for the Roses 2002
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<

Re: [Bitpim-devel] Another developer added to the fold

[Stephen W. <sa...@us...>]

On Tue, 2003-12-16 at 17:03, Roger Binns wrote:

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

Re: [Bitpim-devel] Another developer added to the fold

[Chris C. <cle...@oc...>]

On Tue, 16 Dec 2003, Steven Palm wrote:

> 
> On Dec 16, 2003, at 3:10 PM, Stephen Wood wrote:
> > 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!

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

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
      Support Me Supporting Cancer Survivors in Ride for the Roses 2002
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<

Re: [Bitpim-devel] Another developer added to the fold

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 3:10 PM, Stephen Wood wrote:
> 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 - n9...@n9...
-. ----. -.-- - -.--

Re: [Bitpim-devel] Another developer added to the fold

[Roger B. <ro...@ro...>]

> 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

Re: [Bitpim-devel] libusb / Darwin

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 3:16 PM, Roger Binns wrote:
>>   Just received word back from the Darwin port maintainer of libusb -
>> the changes will be incorporated into the CVS tree soon.
>
> Does it require any changes to the usb.py code in BitPim?

  Not a single line of code. :-)  Even all the autodetect stuff is 
working.  WooHoo. :-)

-. ----. -.-- - -.--
Steve Palm - n9...@n9...
-. ----. -.-- - -.--

Re: [Bitpim-devel] Another developer added to the fold

[Chris C. <cle...@oc...>]

On Tue, 16 Dec 2003, Roger Binns wrote:

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

> 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

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
      Support Me Supporting Cancer Survivors in Ride for the Roses 2002
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<

Re: [Bitpim-devel] Another developer added to the fold

[Stephen W. <sa...@us...>]

On Tue, 2003-12-16 at 16:15, Roger Binns wrote:

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

> 
> 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!

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

Re: [Bitpim-devel] Any Windows registry API experts?

[Jim <Ji...@ja...>]

Ok, will have to look at codebase when I get home.

Just sent you a code example which works here (at work).

If you get a chance, would you send me an export of your USB registry tree for
me to test against?

My lunch break is over now...must get back to "work". :)

Jim West
www.jameswest.com

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


---------- Original Message -----------
From: "Roger Binns" <ro...@ro...>
To: <bit...@li...>
Sent: Tue, 16 Dec 2003 13:26:03 -0800
Subject: Re: [Bitpim-devel] Any Windows registry API experts?

> >   Do you need something "generic" or will something specific with regards to
> > this key tree be acceptable?
> 
> The code already exists.  Look for the 'safegetchildren' method in comscan.py.
> The problem is that for the last 4 out of 22 child entries of a particular
> key on my machine, it returns 234 - More data available.
> 
> The current code uses _winreg.  I also tried using the win32api from 
> win32all and got the same result.
> 
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/regenumkey.asp
> 
> That shows the only way ERROR_MORE_DATA can be returned is if the buffer
> supplied is too small.  However the keys it is falling over on are
> tiny in length so something else is actually happening.  It affecting
> both win32api and _winreg is wierd.
> 
> Roger
> 
> -------------------------------------------------------
> 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
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel
------- End of Original Message -------

Re: [Bitpim-devel] Another developer added to the fold

[Chris C. <cle...@oc...>]

On Tue, 16 Dec 2003, Stephen Wood wrote:

> 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 

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

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

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
      Support Me Supporting Cancer Survivors in Ride for the Roses 2002
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<

Re: [Bitpim-devel] Any Windows registry API experts?

[Roger B. <ro...@ro...>]

>   Do you need something "generic" or will something specific with regards to
> this key tree be acceptable?

The code already exists.  Look for the 'safegetchildren' method in comscan.py.
The problem is that for the last 4 out of 22 child entries of a particular
key on my machine, it returns 234 - More data available.

The current code uses _winreg.  I also tried using the win32api from win32all
and got the same result.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/regenumkey.asp

That shows the only way ERROR_MORE_DATA can be returned is if the buffer
supplied is too small.  However the keys it is falling over on are
tiny in length so something else is actually happening.  It affecting
both win32api and _winreg is wierd.

Roger

Re: [Bitpim-devel] libusb / Darwin

[Roger B. <ro...@ro...>]

Steven Palm wrote:
> On Dec 16, 2003, at 11:42 AM, Steven Palm wrote:
>>  Well, I've properly reworked the darwin implementation of libusb and
>> it seems quite happy now... It can do things it never dreamed of
>> before. :-)
> 
>   Just received word back from the Darwin port maintainer of libusb -
> the changes will be incorporated into the CVS tree soon.

Does it require any changes to the usb.py code in BitPim?

Roger

Re: [Bitpim-devel] Another developer added to the fold

[Roger B. <ro...@ro...>]

> 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

Re: [Bitpim-devel] Another developer added to the fold

[Stephen W. <sa...@us...>]

On Tue, 2003-12-16 at 11:49, Chris Cleeland wrote:
...
> 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

Re: [Bitpim-devel] libusb / Darwin

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 11:42 AM, Steven Palm wrote:
>  Well, I've properly reworked the darwin implementation of libusb and 
> it seems quite happy now... It can do things it never dreamed of 
> before. :-)

  Just received word back from the Darwin port maintainer of libusb - 
the changes will be incorporated into the CVS tree soon.

-. ----. -.-- - -.--
Steve Palm - n9...@n9...
-. ----. -.-- - -.--

Re: [Bitpim-devel] Any Windows registry API experts?

[Jim <Ji...@ja...>]

Roger,

  Do you need something "generic" or will something specific with regards to
this key tree be acceptable?

  Generic being recursive starting from USB key getting/printing everything.

  Specific being just the value set from the ID key under each Vendor/Product
key sans ROOT_HUB.

Jim West
www.jameswest.com

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


---------- Original Message -----------
From: "Roger Binns" <ro...@ro...>
To: <bit...@li...>
Sent: Tue, 16 Dec 2003 10:08:59 -0800
Subject: Re: [Bitpim-devel] Any Windows registry API experts?

> >   Which key?  or can you give me the tree (export from regedit) and I'll look
> > at it.  I've done some registry stuff from both C++ and Python.  It's a beast
> > at best.
> 
> I am enumerating the children of HKLM\System\CurrentControlSet\Enum\USB
> 
> It returns up to the first Vid_1004&Pid_6000 but nothing
> beyond that.
> 
> Roger
------- End of Original Message -------

Re: [Bitpim-devel] Any Windows registry API experts?

[Roger B. <ro...@ro...>]

>   Which key?  or can you give me the tree (export from regedit) and I'll look
> at it.  I've done some registry stuff from both C++ and Python.  It's a beast
> at best.

I am enumerating the children of HKLM\System\CurrentControlSet\Enum\USB

It returns up to the first Vid_1004&Pid_6000 but nothing
beyond that.

Roger

Re: [Bitpim-devel] Another developer added to the fold

[Jim <Ji...@ja...>]

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 <n9...@n9...>
To: bit...@li...
Sent: Tue, 16 Dec 2003 11:35:54 -0600
Subject: Re: [Bitpim-devel] Another developer added to the fold

> On Dec 16, 2003, at 10:49 AM, Chris Cleeland wrote:
> > 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 - n9...@n9...
> -. ----. -.-- - -.--
> 
> -------------------------------------------------------
> 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
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel
------- End of Original Message -------

Re: [Bitpim-devel] libusb / Darwin

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 10:01 AM, Steven Palm wrote:
>  There may yet have to be a third choice. The issue is that once a 
> device is spoken for by a kernel driver, you can not get access to it 
> to configure it. And in order for the phone to function as a network 
> interface via PPP, you have to have the kernel driver loaded, so this 
> is like to be a problem.
>
>  The workaround on the Mac is essentially to bypass the open device, 
> configure, claim interface stuff and maybe jump right to opening the 
> requisite interface on the device. I have done some more reading on 
> this, and I should be able to find the device, enumerate it's 
> interfaces, get vendor/product/protocol information, device 
> descriptor, etc... even if it's claimed by a kernel driver, but I can 
> not open the device itself, only it's unclaimed interface(s). This is 
> where the libusb model breaks down. However, I perhaps can add an 
> additional bit to libusb such as open_usb_interface() as a fallthrough 
> in case opening the device fails.

  Well, I've properly reworked the darwin implementation of libusb and 
it seems quite happy now... It can do things it never dreamed of 
before. :-)

  Because of the fact that the MacOS will allow you to interact somewhat 
with devices even if they are opened exclusively by other processes, I 
took advantage of that. I treat all requests to open a device as 
"partially" successful even if they fail to gain exclusive access. 
Then, in other parts of libusb, things are allowed or disallowed based 
on the type of open they managed to get... So, you can get device 
information, descriptor, interfaces, etc, but you can NOT set 
configuration/etc. You can enumerate and claim interfaces, though, 
provided they are not used by the system.

  So, with this new and improved (?) version of libusb, you get 
something like this from usbscan.py:

UsbScan 7 December 2003

usb::026::002::0:
  active: True  available: False
  description: USB Device - Vendor 0x5ac Product 0x8203 (Interface 0)
  libusb: True  usb-interface: 0  usb-product: 33283  usb-vendor: 1452

usb::059::002::1:
  active: True  available: False
  description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 1)
  libusb: True  usb-interface: 1  usb-product: 24576  usb-vendor: 4100

usb::059::002::2:
  active: True  available: True
  description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 2)
  libusb: True  usb-interface: 2  usb-product: 24576  usb-vendor: 4100

  ...and it works even with the MacOS X driver loaded to supply 
/dev/cu.usbmodemXXX drivers for PPP access.

  I will send this over to the darwin guy at libusb and see what he 
thinks. I'll also start working on the comscan.py module to return 
something meaningful for the Mac. Hopefully. ;-)

-. ----. -.-- - -.--
Steve Palm - n9...@n9...
-. ----. -.-- - -.--

Re: [Bitpim-devel] Another developer added to the fold

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 10:49 AM, Chris Cleeland wrote:
> 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 - n9...@n9...
-. ----. -.-- - -.--

[Bitpim-devel] Increasing baud rate?

[Chris C. <cle...@oc...>]

Phone: sanyo 8100
OS: Linux 2.4.20

Is there a reason that the baud rate must be set at 38400?  When I use the 
phone for PPP connections, it will happily run at 203400; can we use that for 
data transfer, too?

Thanks,
-cj

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
      Support Me Supporting Cancer Survivors in Ride for the Roses 2002
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<

[Bitpim-devel] Another developer added to the fold

[Chris C. <cle...@oc...>]

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

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
      Support Me Supporting Cancer Survivors in Ride for the Roses 2002
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<

Re: [Bitpim-devel] libusb / Darwin

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 12:22 AM, Roger Binns wrote:
> You have two choices as to how to handle USB integration.  One is
> to get libusb working with its current semantics, making tweaks
> as appropriate providing they work on all platforms.
>
> The other choice is a completely seperate usbmac.py file that
> provides the same external API but the internals are different.
> I can make the import process use the correct usb.py/usbmac.py
> file depending on platform.

  There may yet have to be a third choice. The issue is that once a 
device is spoken for by a kernel driver, you can not get access to it 
to configure it. And in order for the phone to function as a network 
interface via PPP, you have to have the kernel driver loaded, so this 
is like to be a problem.

  The workaround on the Mac is essentially to bypass the open device, 
configure, claim interface stuff and maybe jump right to opening the 
requisite interface on the device. I have done some more reading on 
this, and I should be able to find the device, enumerate it's 
interfaces, get vendor/product/protocol information, device descriptor, 
etc... even if it's claimed by a kernel driver, but I can not open the 
device itself, only it's unclaimed interface(s). This is where the 
libusb model breaks down. However, I perhaps can add an additional bit 
to libusb such as open_usb_interface() as a fallthrough in case opening 
the device fails.

  If I added some extra routines to scan the Mac USB bus much like you 
scan the Windows registry in comscan, we could get a list of devices 
and their information for sorting/sifting by comdiagnose.  This is 
probably necessary to get the "auto" port stuff to work anyway, and 
isn't directly related to the issue at hand other than providing a way 
to find the USB device information.

  So, if we have a USB device the kernel (or other driver) has not 
claimed, we can use libusb as it is. However, even if the device itself 
is busy we might be able to get the the interface we need. I don't know 
if you have this capability in Windows or Linux, but this approach 
would almost require saying something like... "If the device is there, 
but busy, and we know which interface we need (or can sort/sift based 
on returned interface information), try to open the interface itself 
directly without regard to the device node."

  If this type of operation is possible on Windows/Linux, we could make 
it an alternate fallback approach if the main device is busy. 
Otherwise, I suppose we could just make this fallback approach 
available on the Mac. The user wouldn't have to do anything different, 
it would all be handled by code.

  Forgive me again if there is rambling and random thoughts here, I'm 
thinking this through and trying to keep this platform consistent. The 
problem here is that all three systems have peculiarities and it's hard 
to try to find a platform independent paradigm and make all of them fit 
into that mold. It's even harder to take a specific platform, say what 
works for Windows, and then try to shoehorn the others to fit that 
mode. Maybe. :-)

-. ----. -.-- - -.--
Steve Palm - n9...@n9...
-. ----. -.-- - -.--