Re: [Bitpim-devel] Patch for GSM phone + MSOutlook read support

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

[Note I will not be applying any of this until after the
weekend build otherwise it won't have had sufficient
testing time]

> I'm sending a patch + zip which adds preliminary support
> for MSOutlook

Although it is a good way of thinking, the current design
doesn't treat non-phone devices as phones.  For the moment
I would prefer to keep Outlook as an import source like
CSV files, not as a phone workalike.

But please do keep thinking about it.  Synchronization 
is going to involve multiple sources and destinations
for data, and the generation of transaction logs.

> appointments.  The "Profile" classes for both probably
> need some work as I'm not really sure what goes on in
> here and where they could inherit from.

Yes, there does need to be a base Profile class.  I guess this
is the spur I need to do that.

> 1. commport.py - add some multi-character terminators,
> might slow things down, but i doubt it is a significant
> performance impact.
> 
> the problem - reads come in spurts, if say wait for a '\r'
> sometimes it will read 'line1\r line2\r line3\r" and
> other times it will return right away after "line1\r"

As far as I can tell you actually need a method corresponding
to the normal Python readline method.  I think that is best
placed in the comm port class.

The reason for the "spurts" is due to lazyness (-ish :-) I
didn't want to have to implement any form of buffers.  There
are two ways to do the readuntil.  One is read one byte at 
a time.  The other is just to read as much as is available
and check the last byte.

The latter approach is very useful with the CDMA phones since
comms with them is somewhat flaky, and you can end up with
previous responses.

However this does all require fixing:

  - Adding a readline method to comm class
  - Adding buffering to comm class (especially for readline)

The comm class needs a method of sending AT commands and
reading the responses, including dealing with echoed commands, OK/ERRORs
and resets.

Can you post what a sequence of commands normally looks like?

> 2. gui.py - skip over serial init routines for non-serial
> devices, tests for existance + trueness of variable in **Phone
> class.

That is only needed if Outlook is treated as a phone which I would
prefer to avoid for the moment.

> 3. GSM driver - labelled as generic, but is probably Samsung
> S105 specific, for sure the calendar stuff is, the phone numbers
> should be generic enough to work across multiple models/vendors.

I think the best thing to do is make a com_obex.py file that does
the GSM stuff and then inherit specific models from that deal
with specific quirks.

Can you also think a bit more about how to specify the protocol
itself?  The current packetdescription stuff is perfect for
binary encodings, but not best suited for CSV style encoding.
I am thinking that printf/scanf style encoding of the packets may
be a better way of dealing with it, quoting issues (double quotes 
and commas in fields), character set encoding etc.

> i added two new classes com_nofiles.py (the non-brew starting point) 

That definitely needs to be added, together with the base
Profile.

The Outlook stuff looks good.  I will have to change the COM gencache
stuff since that won't work in a distributed binary build.

Thanks for the code and updates!

Roger