Qtopia-interest Archive, March 2007
[MOQP] Qtopia and PIM synchronisation
Message 1 in thread
Hello,
as Max is too shy to ask, I will start with some simple questions and
hope he will join with more details.
Back in the old days Qtopia provided a QCOP bridge and Transferserver
on ports 4242 and 4243 which was used for synchronisation. From a
look at the server in Qtopia4.2 this is not supported anymore. Also
the storage format for PIM data was changed from XML to SQLite (both
output formats still exist). From a grep through the files to find
sync information I found the SYNCML_SUPPORT inside the header files
of the PIM classes.
So what is your plan/strategy on synchronisation? I have these open
questions:
-Do you use SyncML, which is simply not available in the Free Version?
-If you use SyncML will it be made available in the Free Version?
-On the Greenphone you seem to have WU-FTP installed, is that your
sync solution?
-If you have a custom sync protocol, where can I find documentation
for it?
-How to remotely find the path to the application files?
-How to remotely find the path to settings and application data
(think of RAPI)
-How do you plan to synchronize PIM and Application Data
-Have you looked at Hiker of PalmSource to easily backup and
transport application data?
-Do you want people to fetch the sqlite database or do you provide a
clever server side support?
-Will you make the source of QtopiaDesktop available to have a
reference synchronisation implementation?
-... many more questions
What I ideally would like to see is having a defined synchronisation
protocol for PIM other Application Data and Settings. This should
include forcing the application to flush data, locking, inform a
connected sync client on changes. Addiotionally I would welcome a
complete SyncML solution. This would ease integrating Qtopia based
solutions on OSX and other great systems like GNU/Linux.
Max had some comments regarding how the internal format of datebook
and contacts makes it hard to synchronize using OpenSync and OSX
iSync. I hope he can spare some details on this topic and that you
look into it.
Looking forward for your answers.
kind regards
h.
PS: You should take a look at Hiker, as this could help to backup
application data easily
--
[ signature omitted ]
Message 2 in thread
Hello,
following some short thoughts from my side regarding PIM:
* User perspective
------------------------
There are several studies on the market evaluating how users use
their mobile phone and what they regard as important feature. Even
though these numbers differ depending on which target group and in
which cultural area was asked, there are three major points. The most
obvious is probably making phone calls. :-). Since this part is
stripped out of the GPL Qtopia PHONE Edition I cannot comment how
good Qtopia works for that.
The second most important point for young people appears to be
"taking photos", but I will ignore this for now. For business people
the second most important point can be summed up as "digital
convergence". One major part of digital convergence is
synchronization of data.
* Market Situation
------------------------
Solutions like Qtopia Desktop are quite "old-fashioned" regarding
synchronization of PIM data (Qtopia Desktop appears to be a mental
copy of Palms Palm Desktop, which was used in a time where the major
OSes did not have any syncing solutions in place). This does not mean
that a solution like Qtopia Desktop is totally superfluous today.
There should be an application on desktop side as counterpart for the
mobile device, e.g. for transferring files, backup of the device etc.
but regarding syncing the PIM data it should not be more than a setup
application on modern desktop OS.
Nowadays Linux has OpenSync (backed by Freedesktop.org and adopted
by Gnome/Evolution and KDE) and Mac OS X has the sync services
framework (since release 10.4). Windows is, as usual, a bit more
complicated due to microsofts marketing/market behavior. Their
ActiveSync is mostly for their own mobile "OS" but there are
solutions to interface with it, and apart from that a connection to
their exchange server is important in the Windows world. Other than
the isolated solution of Qtopia Desktop, these solutions have the
possibility to sync the users PIM data to a wide range of devices and
applications which fulfills the synchronization part of the digital
convergence noted above.
* Qtopia PIM Format
-------------------
The current PIM data schema as shown in Qtopia 4 is an island
solution since it is quite inflexible. Entities like Contacts, Tasks
and Events (Qtopia naming it Appointment) are all stored in one
record. As in the very first version of Qpe (Parent to Qtopia)
Qtopia only supports one Home Address and one Work Address. Similar
inflexibility applies to how phone numbers are handled. There can
e.g. only be one business phone number.
This unflexible format is further cemented by the API. E.g. QContact:
given the combination of the enum PhoneType and the QMap for phone
numbers it is impossible to store two work phone numbers for a
contact. Apart from that, in my personal opinion all the getter and
setter (as e.g. QString businessPhone() ) are unnecessary API bloat.
Qtopia PIM Format and syncing: these above noted inflexibilities
bring immense problems regarding syncing. Most modern PIM frameworks
are more flexible, e.g. allowing to have contacts with an arbitrary
number of telephone numbers and addresses, and especially the
possibility to have e.g. two work telephone numbers. Actually seeing
Qtopia 4.x using a sqlite storage solution it is even more unclear to
me why Qtopia PIM did not change the PIM schemata in version 4.
Legacy cannot be the reason, since there are very few adopters using
the PIM stuff supplied by TT that I know of. E.g. Sharp replaced
Trolltechs solution by their own short after the first release.
* PIM foundation important or not
---------------------------------------------
I know that Trolltechs view on Qtopia was that it is some kind of
framework/foundation that companies could adopt to their own needs.
This leads to many different implementations of base functionality
for a Phone application environment.
As far is I know Trolltechs view changed a bit over the last years on
this matter. I personally would consider a sane PIM foundation
crucial for a phone application platform (what Qtopia wants to be).
This does not mean premium quality GUI apps, this can be left to the
vendors, but a sane foundation pim framework that each adopter should
use. This would not only lead to interoperability between different
Qtopia adopters (on a user basis) but additionally would give
adopters a sane sync solution to all three major OSes out there (of
course only if Trolltech or somebody else provides a sane sync
solution for these OSes).
* Possible future
----------------------
To sum up all my remarks from above I think Trolltech should supply a
PIM framework which is flexible enough to match todays PIM frameworks
on other platforms and while designing this PIM framework Trolltrech
should stick as closely as possible to todays standards.
Additionally, every design decision should be evaluated if it fosters
syncing or hinders syncing.
Kind regards,
Max
[] http://dot.kde.org/1131568739/
Am 04.03.2007 um 00:56 schrieb Holger Freyther:
> Hello,
>
> as Max is too shy to ask, I will start with some simple questions
> and hope he will join with more details.
>
> Back in the old days Qtopia provided a QCOP bridge and
> Transferserver on ports 4242 and 4243 which was used for
> synchronisation. From a look at the server in Qtopia4.2 this is not
> supported anymore. Also the storage format for PIM data was changed
> from XML to SQLite (both output formats still exist). From a grep
> through the files to find sync information I found the
> SYNCML_SUPPORT inside the header files of the PIM classes.
>
> So what is your plan/strategy on synchronisation? I have these open
> questions:
>
> -Do you use SyncML, which is simply not available in the Free
> Version?
> -If you use SyncML will it be made available in the Free Version?
> -On the Greenphone you seem to have WU-FTP installed, is that your
> sync solution?
> -If you have a custom sync protocol, where can I find
> documentation for it?
> -How to remotely find the path to the application files?
> -How to remotely find the path to settings and application data
> (think of RAPI)
> -How do you plan to synchronize PIM and Application Data
> -Have you looked at Hiker of PalmSource to easily backup and
> transport application data?
> -Do you want people to fetch the sqlite database or do you provide
> a clever server side support?
> -Will you make the source of QtopiaDesktop available to have a
> reference synchronisation implementation?
> -... many more questions
>
>
> What I ideally would like to see is having a defined
> synchronisation protocol for PIM other Application Data and
> Settings. This should include forcing the application to flush
> data, locking, inform a connected sync client on changes.
> Addiotionally I would welcome a complete SyncML solution. This
> would ease integrating Qtopia based solutions on OSX and other
> great systems like GNU/Linux.
>
>
> Max had some comments regarding how the internal format of datebook
> and contacts makes it hard to synchronize using OpenSync and OSX
> iSync. I hope he can spare some details on this topic and that you
> look into it.
>
> Looking forward for your answers.
>
> kind regards
> h.
>
> PS: You should take a look at Hiker, as this could help to backup
> application data easily
>
> --
> To unsubscribe - send "unsubscribe" in the subject to qtopia-
> interest-request@xxxxxxxxxxxxx
--
[ signature omitted ]
Message 3 in thread
On Mon, 5 Mar 2007 12:07 am, Maximilian Reiß wrote:
> Hello,
>
> following some short thoughts from my side regarding PIM:
>
Sorry for skipping most of your post in my replies. Take it as understood
that where I don't reply to a point is where I have nothing to add, rather
than refusing to discuss.
> * Qtopia PIM Format
> -------------------
>
> The current PIM data schema as shown in Qtopia 4 is an island
> solution since it is quite inflexible. Entities like Contacts, Tasks
> and Events (Qtopia naming it Appointment) are all stored in one
> record. As in the very first version of Qpe (Parent to Qtopia)
> Qtopia only supports one Home Address and one Work Address. Similar
> inflexibility applies to how phone numbers are handled. There can
> e.g. only be one business phone number.
Flexibility is only one goal of the software, ease of use is another. The
most flexible way of storing contact information would be
recid, valuetype, value
allowing any number of any type of data field. Obviously this isn't what you
are requesting. However allowing multiple business mobile numbers would mean
a function like
contact.businessMobile()
no longer makes sense so it becomes a trade of. Its misleading to say only
one business phone number is allowed, a business land line, business mobile,
business fax and business pager are allowed. And while there is an argument
for more than one Business landline, I don't feel the use case is strong
enough that it is worth providing given the impact on usability.
> This unflexible format is further cemented by the API. E.g. QContact:
> given the combination of the enum PhoneType and the QMap for phone
> numbers it is impossible to store two work phone numbers for a
> contact.
Since this is on the internals of QContact, it can be changed at any time.
However it isn't needed to be changed, insertMulti can insert multiple data
values for a key in a QMap.
void QContact::setPhoneNumber(PhoneType type, const QString &str)
Is what is stopping you having more than one phone number for a single type in
a contact. And I don't intend to change that for reasons stated above, it
would make the API and the application harder to use in return for meeting
fringe use case that can be solved by use of an 'other' phone number type.
> Apart from that, in my personal opinion all the getter and
> setter (as e.g. QString businessPhone() ) are unnecessary API bloat.
They are more convenience functions than bloat. I doubt they count for any
significant proportion of the overall code size.
> Qtopia PIM Format and syncing: these above noted inflexibilities
> bring immense problems regarding syncing.
Come now, immense?
QMap<PhoneType, QString> phoneNumbers() const;
void setPhoneNumber(PhoneType, const QString &);
Yes, you are restricted to a total of 12 phone number types, even less given
the GUI. But I wouldn't call that an immense problem.
> Most modern PIM frameworks
> are more flexible, e.g. allowing to have contacts with an arbitrary
> number of telephone numbers and addresses, and especially the
> possibility to have e.g. two work telephone numbers.
How many people do you know who carry two work mobile phones? Or have two
work landlines that they give out to the same people. How many of those case
wouldn't one be a primary, and the other one 'other'.
> * Possible future
> ----------------------
> To sum up all my remarks from above I think Trolltech should supply a
> PIM framework which is flexible enough to match todays PIM frameworks
> on other platforms and while designing this PIM framework Trolltrech
> should stick as closely as possible to todays standards.
> Additionally, every design decision should be evaluated if it fosters
> syncing or hinders syncing.
The framework should be evaluated on more than just flexibility. Basically I
evaluate design decisions on:
End user usability
Flexibility
Maintainability
Code size
Performance
and a few other metrics. However given this is for a phone, End User
Usability and Performance pretty much trump the others when it comes to a
conflict - which thankfully isn't often.
The PIM API isn't perfect - but its unlikely to be changed in any significant
way. Requests to expose internal functionality may be possible, but changes
to the overall design is unlikely at this point.
--
[ signature omitted ]
Message 4 in thread
Am 06.03.2007 um 05:31 schrieb Ian Walters:
> On Mon, 5 Mar 2007 12:07 am, Maximilian Reiß wrote:
>> Hello,
>>
>> following some short thoughts from my side regarding PIM:
>>
>
> Sorry for skipping most of your post in my replies. Take it as
> understood
> that where I don't reply to a point is where I have nothing to add,
> rather
> than refusing to discuss.
>
>> * Qtopia PIM Format
>> -------------------
>>
>> The current PIM data schema as shown in Qtopia 4 is an island
>> solution since it is quite inflexible. Entities like Contacts, Tasks
>> and Events (Qtopia naming it Appointment) are all stored in one
>> record. As in the very first version of Qpe (Parent to Qtopia)
>> Qtopia only supports one Home Address and one Work Address. Similar
>> inflexibility applies to how phone numbers are handled. There can
>> e.g. only be one business phone number.
>
> Flexibility is only one goal of the software, ease of use is
> another. The
> most flexible way of storing contact information would be
>
> recid, valuetype, value
>
> allowing any number of any type of data field. Obviously this
> isn't what you
> are requesting.
No, I would suggest a Entity-Relationship Modell. Therefore,
modelling the 1:n relationships.
> However allowing multiple business mobile numbers would mean
> a function like
>
> contact.businessMobile()
>
> no longer makes sense so it becomes a trade of. Its misleading to
> say only
> one business phone number is allowed, a business land line,
> business mobile,
> business fax and business pager are allowed. And while there is an
> argument
> for more than one Business landline, I don't feel the use case is
> strong
> enough that it is worth providing given the impact on usability.
But a business fax number is not the same as a business telephone
number. And I know enough contacts who have more than one
"normal" voice telephone number.
>> This unflexible format is further cemented by the API. E.g. QContact:
>> given the combination of the enum PhoneType and the QMap for phone
>> numbers it is impossible to store two work phone numbers for a
>> contact.
>
> Since this is on the internals of QContact, it can be changed at
> any time.
> However it isn't needed to be changed, insertMulti can insert
> multiple data
> values for a key in a QMap.
>
> void QContact::setPhoneNumber(PhoneType type, const QString &str)
>
> Is what is stopping you having more than one phone number for a
> single type in
> a contact. And I don't intend to change that for reasons stated
> above, it
> would make the API and the application harder to use in return for
> meeting
> fringe use case that can be solved by use of an 'other' phone
> number type.
>
>> Apart from that, in my personal opinion all the getter and
>> setter (as e.g. QString businessPhone() ) are unnecessary API bloat.
>
> They are more convenience functions than bloat. I doubt they count
> for any
> significant proportion of the overall code size.
>
>> Qtopia PIM Format and syncing: these above noted inflexibilities
>> bring immense problems regarding syncing.
>
> Come now, immense?
> QMap<PhoneType, QString> phoneNumbers() const;
> void setPhoneNumber(PhoneType, const QString &);
>
> Yes, you are restricted to a total of 12 phone number types, even
> less given
> the GUI. But I wouldn't call that an immense problem.
The problem is, that nearly all desktop solution I know of offers you
_more_. So if you try to sync
your desktop computer with the Qtopia device, you need to start
filtering phone numbers, addresses.
The Problem is not to get the Qtopia Data on the desktop, but the
other way around. Qtopia only supports a
small subset of what a users PIM database on the desktop might look
like. So while syncing there are decisions to make:
Which of the two home addresses should I push to the users Qtopia
device? What if its not the one he needs more for that contact?
When I sync back, how do I identify which of the different addresses
was it (imporant if a property changed on the Qtopia device)? For
this solution some unique IDs would be needed, and this not only for
each entity like a contact, but as well for each telephone number,
address ....
You can say that many other phones do not support more either, but
that mostly applies to consumer products (low end) and
actually, where is this a reason not to do it better.
>> Most modern PIM frameworks
>> are more flexible, e.g. allowing to have contacts with an arbitrary
>> number of telephone numbers and addresses, and especially the
>> possibility to have e.g. two work telephone numbers.
>
> How many people do you know who carry two work mobile phones? Or
> have two
> work landlines that they give out to the same people. How many of
> those case
> wouldn't one be a primary, and the other one 'other'.
I just know that my personal addressbook database has plenty of these
cases, and the addressbooks
of my beta testers apparently as well.
>
>> * Possible future
>> ----------------------
>> To sum up all my remarks from above I think Trolltech should supply a
>> PIM framework which is flexible enough to match todays PIM frameworks
>> on other platforms and while designing this PIM framework Trolltrech
>> should stick as closely as possible to todays standards.
>> Additionally, every design decision should be evaluated if it fosters
>> syncing or hinders syncing.
>
> The framework should be evaluated on more than just flexibility.
> Basically I
> evaluate design decisions on:
>
> End user usability
> Flexibility
> Maintainability
> Code size
> Performance
>
> and a few other metrics. However given this is for a phone, End User
> Usability and Performance pretty much trump the others when it
> comes to a
> conflict - which thankfully isn't often.
>
End user usability would be improved.
> The PIM API isn't perfect - but its unlikely to be changed in any
> significant
> way. Requests to expose internal functionality may be possible,
> but changes
> to the overall design is unlikely at this point.
>
> --
> Ian.
---
Max
--
[ signature omitted ]
Message 5 in thread
On Tue, 6 Mar 2007 05:37 pm, Maximilian Reiß wrote:
> > However allowing multiple business mobile numbers would mean
> > a function like
> >
> > contact.businessMobile()
> >
> > no longer makes sense so it becomes a trade of. Its misleading to
> > say only
> > one business phone number is allowed, a business land line,
> > business mobile,
> > business fax and business pager are allowed. And while there is an
> > argument
> > for more than one Business landline, I don't feel the use case is
> > strong
> > enough that it is worth providing given the impact on usability.
>
> But a business fax number is not the same as a business telephone
> number. And I know enough contacts who have more than one
> "normal" voice telephone number.
At this time the feature of an arbitrary number of phone numbers per contact
has no justifiable use-cases, for instance
Home Phone
Split-family home phone
holiday home
business phone
remote office business phone.
and so on may exist for a contact... however to claim this makes up the
majority of contacts doesn't scan. Yes, for this contact the usability is
harder. For the majority its easier.
You will just have to accept, that at this time, I will not be changing this
aspect of the PIM Library design. Possibly in the future, but not the
forseeable future. If this means you feel you can't use the PIM library that
is a decision you will have to make and I'll have to accept.
--
[ signature omitted ]
Message 6 in thread
Am 06.03.2007 um 09:12 schrieb Ian Walters:
> You will just have to accept, that at this time, I will not be
> changing this
> aspect of the PIM Library design. Possibly in the future, but not the
> forseeable future. If this means you feel you can't use the PIM
> library that
> is a decision you will have to make and I'll have to accept.
It is not about the PIM Library. As Max stated in his previous mail
it is about syncing a desktop machine (think of Kontact, Evolution or
OSX stuff) with a Qtopia device. The desktop side is using ical/vcard
as their data model, the Qtopia PIM model is not compatible, it is a
small subset. This means for synchronisation solutions (like
OpenSync, Sync Framework) that tradeoffs needs to be made (like
stated by Max) (e.g. choosing any address instead of all).
The user will suffer. I don't want the user to suffer, do you?
Obviously you could make a difference. And this is only about the
model itself, not about the representation to the user.
h.
PS: It would be appreciated if you could post a preview of your spec
for public review
--
[ signature omitted ]
Message 7 in thread
On Tue, 6 Mar 2007 08:03 pm, Holger Freyther wrote:
> Am 06.03.2007 um 09:12 schrieb Ian Walters:
> > You will just have to accept, that at this time, I will not be
> > changing this
> > aspect of the PIM Library design. Possibly in the future, but not the
> > forseeable future. If this means you feel you can't use the PIM
> > library that
> > is a decision you will have to make and I'll have to accept.
>
> It is not about the PIM Library. As Max stated in his previous mail
> it is about syncing a desktop machine (think of Kontact, Evolution or
> OSX stuff) with a Qtopia device. The desktop side is using ical/vcard
> as their data model, the Qtopia PIM model is not compatible, it is a
> small subset.
This is all true. However it will always be true that one PIM model is a
subset (or even merely just have overlap) with another. If all PIM models
were equal there would be less to choose between.
> This means for synchronisation solutions (like
> OpenSync, Sync Framework) that tradeoffs needs to be made (like
> stated by Max) (e.g. choosing any address instead of all).
Exactly.
> The user will suffer. I don't want the user to suffer, do you?
No, I don't. Unfortunately one must often choose between suffering. The
more that the user can add to a contact, the more the dialog needs to
present, the more it presents, the more cluttered it is, the more cluttered,
the harder it is to enter the most common information.
There are of course solutions to this, but they become less trivial the more
information you allow to be attached to a single contact. That is the cost
I'm trying to point out.
> Obviously you could make a difference. And this is only about the
> model itself, not about the representation to the user.
The model itself should already handle multiple BusinessHomePhone numbers per
contact, and if it doesn't I consider it a bug. The API however does not
expose this in an accessable way and I won't be changing that until the UI
issues are also resolved.
If there is data that can't be shown to the user, the common response is to
save those fields in setCustomField. This retains the data for syncing (e.g.
you won't lose it) but at the same time doesn't add a requirement that
attached UI should show that information.
As long as you are not talking about the API or the UI, I have no problem with
storing multiple BusinessHomePhone's per contact.
> PS: It would be appreciated if you could post a preview of your spec
> for public review
Hrm, that might be embarrassing (for me personally). The current requirement
priority is 'working outlook sync solution as soon as possible'. Extensable
is not actually main goal at the moment.
What I'd rather do is aid Opie in integrating an existing Opie preferred sync
solution into Qtopia. Possibly making it a GPL only feature if the license
works that way.
If you can get something working that syncs to a vCard/vCal store on Qtopia
that doesn't touch the PIM lib, I'd be happy to help with the QPim record
class conversions and moving the code to the appropriate places in the PIM
library.
--
[ signature omitted ]
Message 8 in thread
On Tue, 6 Mar 2007 08:03 pm, Holger Freyther wrote:
> Am 06.03.2007 um 09:12 schrieb Ian Walters:
> PS: It would be appreciated if you could post a preview of your spec
> for public review
A thought under consideration....
What I could do is expose functions in the public API that allow the
application to sync in whatever means it pleases. The PIM library already
keeps a change log, so I could expose functions for what has changed, removed
or added since a specified timestamp and collection of QPimSource's. I could
then expose the internal functions that prepare a source for syncing,
currently....
static QDateTime lastSyncTime(const QPimSource &);
static bool setLastSyncTime(const QPimSource &, const QDateTime &);
bool startSync(const QList<QPimSource> &, const QDateTime &syncTime);
bool abortSync();
bool commitSync();
The above functions simply make it so the modifications of a sync are done in
with a single timestamp for each record affected and that they go through in
a transaction.
Providing these functions would remove reliance on Qtopia's Sync specification
since you would essentially be able to ignore it and implement whatever you
wanted, at the application level if preferred. The motivation for me is one
of clean code separation. It means I can provide a 'sync' class separate
from the rest of the pim code which means I can improve it with greater ease
at a later date. This also would not be an design change, mostly its just
moving functions that have been tested internally in the library to also
exist externally.
Just thought I'd get your thoughts on this before I went too far down either
path. (and those thoughts of anyone else on this list).
--
[ signature omitted ]
Message 9 in thread
Am 09.03.2007 um 00:23 schrieb Ian Walters:
Hi Ian,
I have two thoughts to spare.
> On Tue, 6 Mar 2007 08:03 pm, Holger Freyther wrote:
>> Am 06.03.2007 um 09:12 schrieb Ian Walters:
>> PS: It would be appreciated if you could post a preview of your spec
>> for public review
>
> A thought under consideration....
>
> What I could do is expose functions in the public API that allow the
> application to sync in whatever means it pleases. The PIM library
> already
> keeps a change log, so I could expose functions for what has
> changed, removed
> or added since a specified timestamp and collection of
> QPimSource's. I could
> then expose the internal functions that prepare a source for syncing,
> currently....
>
> static QDateTime lastSyncTime(const QPimSource &);
> static bool setLastSyncTime(const QPimSource &, const QDateTime &);
> bool startSync(const QList<QPimSource> &, const QDateTime &syncTime);
> bool abortSync();
> bool commitSync();
I think there are at least two issues with this:
-You rely on time and on battery powered devices the time might just
reset
-The user might travel and switches timezones so the time can be off
a lot
-You limit syncing to just one host. But this is not practical. E.g.
I have Palm users that sync to their home machine, backup machine and
laptop. With just one date you don't help them
So what I propose is a slight backward concept. Keep a revision
number (monotonely increasing) for each record. This case a sync
client only needs to remember the UIDs and RevNumber to find changes
regardles of who else synced with the device.
Increasing of version numbers would be done automatically to the
record whenever you change it, so no abortSync or commitSync is
needed, only startSync and stopSync to get locked access to the
database. Even wrap arounds can be handled.
>
> The above functions simply make it so the modifications of a sync
> are done in
> with a single timestamp for each record affected and that they go
> through in
> a transaction.
>
> Providing these functions would remove reliance on Qtopia's Sync
> specification
> since you would essentially be able to ignore it and implement
> whatever you
> wanted, at the application level if preferred. The motivation for
> me is one
> of clean code separation. It means I can provide a 'sync' class
> separate
>> from the rest of the pim code which means I can improve it with
>> greater ease
> at a later date. This also would not be an design change, mostly
> its just
> moving functions that have been tested internally in the library to
> also
> exist externally.
I like the idea but this creates a new problem. If we write a sync
daemon with our own protocol. How to install it on a consumer device?
E.g. how to install the 'signed' community package remotely and make
it run as daemon on Qtopia start. AFAIK there is no concept of
AutoStart or daemon within Qtopia and if we get run in the SXE can we
still access settings, pim database and do network connections?
But besides that I really like the idea.
kind regards
holger
--
[ signature omitted ]
Message 10 in thread
On Fri, 9 Mar 2007 10:13 am, you wrote:
> Am 09.03.2007 um 00:23 schrieb Ian Walters:
>
> Hi Ian,
>
> I have two thoughts to spare.
>
> > On Tue, 6 Mar 2007 08:03 pm, Holger Freyther wrote:
> >> Am 06.03.2007 um 09:12 schrieb Ian Walters:
> >> PS: It would be appreciated if you could post a preview of your spec
> >> for public review
> >
> > A thought under consideration....
> >
> > What I could do is expose functions in the public API that allow the
> > application to sync in whatever means it pleases. The PIM library
> > already
> > keeps a change log, so I could expose functions for what has
> > changed, removed
> > or added since a specified timestamp and collection of
> > QPimSource's. I could
> > then expose the internal functions that prepare a source for syncing,
> > currently....
> >
> > static QDateTime lastSyncTime(const QPimSource &);
> > static bool setLastSyncTime(const QPimSource &, const QDateTime &);
> > bool startSync(const QList<QPimSource> &, const QDateTime &syncTime);
> > bool abortSync();
> > bool commitSync();
>
> I think there are at least two issues with this:
> -You rely on time and on battery powered devices the time might just
> reset
I don't see how. if the device resets while a sync is in progress the
transaction by definition is canceled. The resulting state would be...
Transaction cancelled by database, no data changed, host has no confirmed
sync. State is same as pre-sync.
Database committed but confirmation to host is not sent. On next sync
redundant information would be sent, but all changes would still be covered.
> -The user might travel and switches timezones so the time can be off
> a lot
Timezones won't affect it, timestamps are in utc, not local. Changing time
and resyncing would affect it, however this isn't a common case.
> -You limit syncing to just one host.
No, it doesn't. The change log isn't kept 'since last sync'. Its kept for
all records indefinitely. From the clients point of view a sync with a
separate host looks the same as a batch change by the user.
To go back to your revision number idea, timestamps do monotonely increase,
the only real differences is they are affected by the user changing the clock
and they have gaps. Going with timestamps though to fit with the SyncML
specification.
> I like the idea but this creates a new problem. If we write a sync
> daemon with our own protocol. How to install it on a consumer device?
> E.g. how to install the 'signed' community package remotely and make
> it run as daemon on Qtopia start. AFAIK there is no concept of
> AutoStart or daemon within Qtopia and if we get run in the SXE can we
> still access settings, pim database and do network connections?
The 'how is it installed' issue is present. However we don't 'sign'. The
security framework puts the responsibility for trust in the hands of the
user, telling the user what the program will want to do and letting the user
make an informed decision of trust. Basically the install idea would need to
be visited. However this applies to a class of applications outside of
syncing, so not really part of this scope. More, 'this may not be a complete
solution to the issue'.
I'll continue looking at making the required functions available, and send
info on what the pre-installed protocol looks like as I get further along.
--
[ signature omitted ]
Message 11 in thread
I'll answer the one I can ;) Being the Docapi/qtopiasql.cpp guy.
Holger Freyther wrote:
> Hello,
>
> as Max is too shy to ask, I will start with some simple questions and
> hope he will join with more details.
>
> -Do you want people to fetch the sqlite database or do you provide
> a clever server side support?
As of 4.2 there are two documents on Database policy, and Database
specification that give you some rules on using the database. As of
4.2.2, we're moving to a database per application model preference.
Moving towards 4.3, qpe will serve all database needs in a think
client/server model mostly for the Document and possibly PIM models. One
thing to keep in mind also, we have taken into account integration of
other database engines (eg mimer), so make sure you rely on the apis for
getting access to data in the system databases, these will be guaranteed
to be binary compatible and consistent once SXE becomes released to the
mainstream (4.3). Hope this helps a little.
>
> Looking forward for your answers.
>
> kind regards
> h.
>
> PS: You should take a look at Hiker, as this could help to backup
> application data easily
Thanks for the headsup, I will :) (and as I'm most likely to be the one
to ressurect backup of settings in the near future). It's all a matter
of man-hours, and if this helps reduce them... :)
--
[ signature omitted ]
Message 12 in thread
Am 04.03.2007 um 23:27 schrieb Bill KING:
> I'll answer the one I can ;) Being the Docapi/qtopiasql.cpp guy.
>
> Holger Freyther wrote:
>> Hello,
>>
>> as Max is too shy to ask, I will start with some simple questions and
>> hope he will join with more details.
>>
>> -Do you want people to fetch the sqlite database or do you
>> provide
>> a clever server side support?
> As of 4.2 there are two documents on Database policy, and Database
> specification that give you some rules on using the database. As of
> 4.2.2, we're moving to a database per application model preference.
> Moving towards 4.3, qpe will serve all database needs in a think
> client/server model mostly for the Document and possibly PIM
> models. One
> thing to keep in mind also, we have taken into account integration of
> other database engines (eg mimer), so make sure you rely on the
> apis for
> getting access to data in the system databases, these will be
> guaranteed
> to be binary compatible and consistent once SXE becomes released to
> the
> mainstream (4.3). Hope this helps a little.
Hello Bill,
thanks for the answer so to summarize it: Currently it is not
possible to synchronize with Qtopia in a way that it will work with
4.2.2 and 4.3?
Is this client server model intended to be used by synchronisation
frameworks? Will it be possible to get a list of
'resources' (configuration files, pim data and application data) and
see the time of their last cange?
Do you plan to write a spec for this model and make it freely
available for the people using synchronisation frameworks to write
plugins?
kind regards
h.
--
[ signature omitted ]
Message 13 in thread
Holger Freyther wrote:
>
> Am 04.03.2007 um 23:27 schrieb Bill KING:
>
>> I'll answer the one I can ;) Being the Docapi/qtopiasql.cpp guy.
>>
>> Holger Freyther wrote:
>>> Hello,
>>>
>>> as Max is too shy to ask, I will start with some simple questions and
>>> hope he will join with more details.
>>>
>>> -Do you want people to fetch the sqlite database or do you provide
>>> a clever server side support?
>> As of 4.2 there are two documents on Database policy, and Database
>> specification that give you some rules on using the database. As of
>> 4.2.2, we're moving to a database per application model preference.
>> Moving towards 4.3, qpe will serve all database needs in a think
>> client/server model mostly for the Document and possibly PIM models. One
>> thing to keep in mind also, we have taken into account integration of
>> other database engines (eg mimer), so make sure you rely on the apis for
>> getting access to data in the system databases, these will be guaranteed
>> to be binary compatible and consistent once SXE becomes released to the
>> mainstream (4.3). Hope this helps a little.
>
>
> Hello Bill,
>
> thanks for the answer so to summarize it: Currently it is not possible
> to synchronize with Qtopia in a way that it will work with 4.2.2 and 4.3?
>
> Is this client server model intended to be used by synchronisation
> frameworks? Will it be possible to get a list of 'resources'
> (configuration files, pim data and application data) and see the time
> of their last cange?
>
> Do you plan to write a spec for this model and make it freely
> available for the people using synchronisation frameworks to write
> plugins?
>
> kind regards
> h.
>
> --
> To unsubscribe - send "unsubscribe" in the subject to
> qtopia-interest-request@xxxxxxxxxxxxx
>
>
Can't answer these questions at this point in time, sorry, for various
reasons (PIM is not my section, not sure of future directions of pim,
etc). I will however make sure the appropriate devs see this thread (if
this helps any).
--
[ signature omitted ]
Message 14 in thread
On Sun, 4 Mar 2007 09:56 am, Holger Freyther wrote:
> Hello,
>
> So what is your plan/strategy on synchronisation? I have these open
> questions:
>
> -Do you use SyncML, which is simply not available in the Free Version?
Not directly. One of our partners are Teleca, who's SyncML integration
information can be seen here:
http://www.qtopiagreenphone.com/trolltech/pdf/TelecaSolutionBrief_web.pdf
> -If you use SyncML will it be made available in the Free Version?
If we use SyncML, it will be in the Free Version. This isn't set in stone at
the moment. However I doubt the partner solution will be in the Free
Version.
> -On the Greenphone you seem to have WU-FTP installed, is that your
> sync solution?
No, that is for developer use. At this point we have no plans on using FTP as
part of sync.
> -If you have a custom sync protocol, where can I find documentation
> for it?
You can't find documentation on it because it doesn't exist. The previous
design in Qtopia 2 of using the files on flash is not appropriate given the
database storage. Right now I'm working on a sync protocol that involves
directly writing the information over the transport (not set in stone yet)
rather than writing to a file then sending the file over the transport.
In fact this answer applies to a lot of the other questions as well. There is
no information on the how or the plan to's since we haven't made those
decisions yet.
> -Have you looked at Hiker of PalmSource to easily backup and
> transport application data?
Not yet. I'll look at it today.
> -Do you want people to fetch the sqlite database or do you provide a
> clever server side support?
Will definitely be client-server. The SQL nature of PIM will not be exposed
in the Sync protocol. At this point the representation format for PIM data
is likely to be vCard and vCalendar.
> -Will you make the source of QtopiaDesktop available to have a
> reference synchronisation implementation?
> -... many more questions
'
QtopiaDesktop as such is unlikely to be part of Qtopia 4. Essentially any
Qtopia desktop code would be simply a sync assist at the moment.
> What I ideally would like to see is having a defined synchronisation
> protocol for PIM other Application Data and Settings.
I'd like to see that to. It would save me some work in designing it.
Basically I'm not far enough along to give you any real answer yet.
--
[ signature omitted ]
