[Bug 679] New: libsynthesis: better configuration mechanism + debugging
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=679
Summary: libsynthesis: better configuration mechanism +
debugging
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: enhancement
Priority: Low
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This is from http://bugzilla.moblin.org/show_bug.cgi?id=3471
The compile-time configuration of libsynthesis is done via a static
target_options.h file. On Linux with configure it would be more natural to let
configure options determine at least some of the aspects currently fixed in
target_options.h.
src/Makefile.am.in describes in which order header files are included.
To give one example, debugging of low-level SyncML Toolkit issues becomes
easier with the following change to target_options.h:
-#define RELEASE_VERSION
+// #define RELEASE_VERSION
#define RELEASE_SYDEBUG 2 // extended DBG included
//#define OPTIONAL_SYDEBUG 1
@@ -24,6 +24,7 @@
// now include platform independent product options (which include
global_options.h)
#include "product_options.h"
+#define CONSOLEINFO
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 678] New: push notification: via email and IMAP IDLE
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=678
Summary: push notification: via email and IMAP IDLE
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: enhancement
Priority: Low
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This is from BMO#3313 (http://bugzilla.moblin.org/show_bug.cgi?id=3313)
This is another crazy (or not so crazy) feature idea...
Currently a SyncML client has no way of knowing whether the server data has
changed short of regularly running a sync session. "Push technology" is the
term which typically describes a system where the server sends new data to
clients immediately, or at least with a very minimal delay.
One way to achieve this is to send a short notification if new data is
available and have the client pull that data using its normal methods, like a
SyncML session.
Funambol implements one such notification method. It relies on
Funambol-specific protocols and a TCP connection from the client to the server
or vice versa (depending on the specific method). Funambol then uses SyncML to
transfer email.
Now assume that we have a method of transferring email to a client almost
instantaneously. Whenever its data changes, the server could send an email to
the client, probably batching changes to avoid excessive notifications. The
client receives the email, its mail client software recognizes the special
email and notifies the sync program, which runs a sync to pull the data.
IMAP IDLE is such an almost instantaneous notification mechanism. It is likely
to be supported by Anjal [1], the Moblin mail program developed by Novell. For
this system to work we would need:
* a format for notification emails (reuse SMS format?)
* a server-side component which generates them
* a plugin for Anjal which handles them
* a D-Bus API for syncevolution to start the sync
This solution does not depend on IMAP IDLE. It will still be more effective
than polling for SyncML changes and email separately if just the mail client
polls for new email.
There are some issues with the email approach: who deletes the email? It would
be useful to use the email as broadcast to all clients of the user (for
example, desktop and netbook), but then it has to remain on the server after
the first client has seen it. It might be easier to send one email per client
and let that client delete its email.
What if that client never sees the email or only very late? Can we get the
email automatically deleted after a certain period of time, or when a newer
email has arrived?
Perhaps using a special IMAP folder on the server would do the trick. It could
be cleaned by an agent accessing it regularly. The agent could run as part of
the IMAP server or on a separate server.
[1] http://live.gnome.org/Anjal
------- Comment #1 From jku 2009-06-11 07:09:10 PST (-) [reply] -------
(In reply to comment #0)
> This is another crazy (or not so crazy) feature idea...
I was asking David Woodhouse for comments on the possible (non)craziness.
"makes some sense" was the general comment. Some specific notes:
* in imap you can put arbitrary flags on messages, so clients could mark it as
'seen by client X' when they've dealt with it
Not sure if this helps in removing the messages (the problem is still that no
client really knows all the other clients: only the server could keep a list).
* I might be slightly more inclined to do it over xmpp/sip/etc than imap
Now this is an interesting idea, especially XMPP. It's pretty much made for
this sort of thing (see pubsub*) and we have telepathy in moblin already.
Whether this is easier or harder to sell to server developers is another
question but technically it sounds more "correct" than using email...
Unsurprisingly this wouldn't be the first time xmpp is used for push
notifications, it looks like the newest iphone OS does that as an example.
*) http://xmpp.org/extensions/xep-0060.html
http://www.coverfire.com/archives/2006/04/25/jabberxmpp-pubsub/
------- Comment #2 From pohly 2009-06-12 11:30:45 PST (-) [reply] -------
(In reply to comment #1)
> * I [David Woodhouse] might be slightly more inclined to do it over xmpp/sip/etc than imap
>
> Now this is an interesting idea, especially XMPP. It's pretty much made for
> this sort of thing (see pubsub*) and we have telepathy in moblin already.
> Whether this is easier or harder to sell to server developers is another
> question but technically it sounds more "correct" than using email...
I agree, both on "more correct" and "harder to sell". I bet all servers will
have SMTP support and an email address on file for their users, but not XMPP
support.
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 677] New: libsynthesis: field list <-> XML conversion
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=677
Summary: libsynthesis: field list <-> XML conversion
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: NEW
Severity: enhancement
Priority: Low
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This issue is from BMO#3311 (http://bugzilla.moblin.org/show_bug.cgi?id=3311)
This is a (perhaps crazy) idea, but let me describe it anyway...
Currently the Synthesis engine can convert the internal field lists to plain
text, email, SQL databases (via ODBC) and last but not least, MIME based
formats. It might also be useful to have an automatic conversion to and from
XML, in particular if the database side stores items in XML.
The Synthesis engine could use an XML format that is directly derived from the
field list. Then XSLT transformations could be used to process and generate
that Synthesis format from some other, custom format used by the database. This
transformation could be executed by the Synthesis engine itself, which would
depend on additional configuration mechanisms to specify the transformation.
Alternatively the engine could be configured so that it reads/writes some
custom XML format directly. It might be hard to make this configurable enough
to cover a wide range of XML formats, so I kind of prefer the XSLT approach
above.
One use case of this new feature is support for OpenSync's XML PIM formats
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 675] New: rewrite synccompare in C++
by bugzilla＠meego.com
http://bugzilla.meego.com/show_bug.cgi?id=675
Summary: rewrite synccompare in C++
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: NEW
Severity: enhancement
Priority: Low
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
This issue is from BMO#2432 (http://bugzilla.moblin.org/show_bug.cgi?id=2432)
Currently synccompare is a Perl script because that was the easiest way to have
regular search/replace on all platforms. For performance reasons and for better
control of the result, a rewrite in C++ would be useful.
Need to add better description of the task, thus assigned to me.
------- Comment #1 From pohly 2009-06-08 07:42:59 PST (-) [reply] -------
synccompare is a tool which turns sets of contacts or calendar items into a
normal form that is slightly easier to read:
* uses indention for BEGIN/END pairs
* same order of properties and values
* no redundant default values
* configurable line length
* etc.
In addition, it compares two sets and prints items which differ (and only those
items) in a side-by-side comparison similar to a context diff. The return code
indicates whether changes were found. The heading is configurable.
A normal form is necessary before comparison because vCard and iCalendar allow
many different equivalent formats for the same information.
synccompare is used by the syncevolution command line to report data changes.
It is used by client-test to find unwanted data modifications during testing.
For that second role, synccompare also supports transformations in the normal
form which are caused by known server deficiencies. For example, suppose server
foo doesn't property BAR. This would show up in the diff of
Client::Sync::*::testItems as a lost property BAR. When invoked with
CLIENT_TEST_SERVER=foo, synccompare will remove all properties BAR and thus the
diff succeeds.
synccompare is meant to find defects in the PIM data handling code used by
SyncEvolution. Therefore it cannot rely on that same code to generate the
normal form. Otherwise a bug which, f.i., drops a property would affect the
sync and the verification the same way and not show up in the diff.
Currently synccompare uses regular expression search/replace to manipulate
vCard 3.0 and iCalendar 2.0 data. These formats are regular enough to do simple
transformations (line unfolding) via regular expressions. vCard 2.1 and
vCalendar 1.0 have more difficult folding rules and therefore do not work 100%
correctly at the moment. It would be good to also support them.
synccompare is implemented as a Perl script because that is the most widely
deployed implementation of regular expression search/replace with UTF-8 support
(useful for correct line length calculation!). It's also fairly simple to come
up with quick hacks for normalization... but it is hard to maintain and has
performance issues.
A rewrite with C++ and suitable libraries (Boost?) might overcome these
limitations. Transformations should be specified in a custom, higher-level
format instead of s// statements in the source code (to be defined - perhaps a
configurable list of regular expressions?). Not all target platforms will
necessarily have these libraries, so it might be useful to keep the Perl script
around and perhaps rewrite it so that it uses the same configuration.
I already implemented a better diff algorithm in C++. "Better" in the sense
that if there are are two equally short diffs, it will pick the one which
covers less items. I have the code somewhere, need to upload it here.
------- Comment #2 From pohly 2009-06-12 07:21:31 PST (-) [reply] -------
Created an attachment (id=1154)
--> (http://bugzilla.meego.com/attachment.cgi?id=1154) [details]
longest common sequence implementation with a notion of "better" sequences
This is the code which might be useful for implementing the diff in synccompare
in C++.
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12 years, 5 months
[Bug 10204] New: Please also register SyncML server service record in obexd
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=10204
Summary: Please also register SyncML server service record in
obexd
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: forrest.zhao(a)intel.com
ReportedBy: congwu.chen(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution(a)lists.intel.com
Obexd SyncEvolution plugin currently registered a SyncML client service record
on channel 16. SyncEvolution actually supports both SyncML server and client
service, thus it would be better if we can also register a SyncML server
service record (on the same channel).
Please refer to Table 1 in OMA-TS-SyncML_OBEXBinding-V1_2-20070221-A about the
SyncML Server Service Record structure.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 5 months