[Bug 7213] New: OBEX support SyncML client
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7213
Summary: OBEX support SyncML client
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Depends on: 6175
Release Milestone: Undecided
A mobile device typically provides an OBEX/Bluetooth server which accepts
connections from a SyncML server running on a desktop or laptop. As a first
step we want to be compatible with SyncEvolution as SyncML server.
One component for this feature is a obexd plugin which uses the new Connection
D-Bus API to route SyncML traffic into SyncEvolution. The other component is
the Connection API implementation in SyncEvolution itself.
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 7873] New: OBEX support SyncML server ("sync with phones")
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7873
Summary: OBEX support SyncML server ("sync with phones")
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P1
Component: *Feature Request
AssignedTo: congwu.chen(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Depends on: 5188,7214,7838,7871
To synchronize with a phone, SyncEvolution must
- be able to act as SyncML server (bug #7214)
- initiate the OBEX connection (bug #5188)
- generate a Server Alerted Sync (SAN) message (bug #7871)
- handle the SyncML session initiated by the device
This all depends on having a correct local configuration for the phone.
Creating such a configuration in a user-friendly way is yet another open
problem (bug #7838)
--
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
[Bug 7214] New: SyncML server
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7214
Summary: SyncML server
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: major
Priority: P1
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Depends on: 4774,4815,5188,6303,6379,7089
Release Milestone: Undecided
For direct synchronization with other devices, SyncEvolution must be able to
act as a SyncML server and be able to connect to those devices via
OBEX/Bluetooth. It must contact these devices in such a way that they accept
the connection and start syncing. This is highly device specific, so the
initial goal is a proof-of-concept with some devices.
Privacy-aware power users don't want to put their data into the hands of
service providers in the Internet. For those and for testing purposes we should
also provide at least rudimentary support for running SyncEvolution as HTTP
server.
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 7893] New: performance and reliability improvements
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7893
Summary: performance and reliability improvements
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P2
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Depends on: 2416,3479,6365
Another meta issue, depending on issues which are related to performance and/or
reliability.
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 8730] New: improve integration of suspend/abort with transports
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8730
Summary: improve integration of suspend/abort with transports
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Discussion started as part of bug #6376.
Congwu pointed out that the ObexTransportAgent has to use polling to check for
the internal suspend/abort flags (SyncContext::getSuspendFlags()). This ignores
abort requests coming in via the D-Bus API, which are only checked at the
higher layers once the ObexTransportAgent returns because it has data.
The DBusTransportAgent also has a TODO around adding the regular callbacks into
the caller. I think it does not check the abort request triggered by signals,
which depends on these callbacks.
Here's an idea for a better architecture:
- instead of using global SuspendFlags, introduce two pipes,
one for suspend, one for abort
- the signal handler writes one byte into one end of these
to flag "suspend and/or abort requested"
- so does the D-Bus API implementation
- the other end of the pipes can be checked for readability
*without* actually reading the byte
- most event systems can watch for a file descriptor, so
we can (but don't have to) get rid of polling
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 7838] New: creating client configurations
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Summary: creating client configurations
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: major
Priority: P2
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Right now, SyncEvolution as server expects that a configuration for a client
peer exists before the peer is able to synchronize (bug #7710). Creating the
configuration requires the client's device ID.
Here's the catch 22: that device ID typically cannot be determined unless the
client synchronizes or at least attempts to synchronize...
We could break that bind by:
- allowing the client to connect
- determine that it has no config yet
- ask the user whether he wants to allow the client to
connect and how
- create the config
- continue with it
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 7709] New: server progress events
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7709
Summary: server progress events
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P2
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
When the Synthesis engine runs in server mode, it doesn't produce progress
events. According to Lukas, some heavy code refactoring would be needed to get
the progress from the client engine to the shared base class.
The effect on SyncEvolution is that when starting a sync with a phone, our
sync-UI does not show any progress. We also don't show and store statistics. We
want the usage as client and server to be as similar as possible, so we need to
get the progress events into the Synthesis server engine or stop depending on
them.
Perhaps by producing our own events inside the SynthesisDBInterface or a mix-in
class for backends? Refactoring the server code might be easier.
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 7163] New: command line: clone configs
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7163
Summary: command line: clone configs
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P3
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Release Milestone: Undecided
For ScheduleWorld it is necessary to create two configurations when
synchronizing two calendars. In the new config scheme proposed for 1.0, the
calendar source must have different names. Currently this prevents using the
ScheduleWorld calendar template, because the different name doesn't match.
"Cloning" template or configuration nodes could be added to the command line
like this:
--configure --template scheduleworld scheduleworld_home
calendar_home=calendar
The semantic would be "populate the source properties for 'calendar_home' with
the source properties of "calendar".
Likewise, we could clone an existing configuration and thus avoid setting the
credentials twice:
--configure scheduleworld_home=scheduleworld
--
Configure bugmail: http://bugzilla.moblin.org/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
[Bug 6456] New: syncevolution --version: information about backends?
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=6456
Summary: syncevolution --version: information about backends?
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: congwu.chen(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com
Release Milestone: Undecided
What information do we want to display to users about backends?
In 0.9, "syncevolution --version" didn't print anything about them.
In the current "master", it prints:
Scanning backend libraries in backends/
Scanning backend libraries in backends/addressbook/.libs/
Scanning backend libraries in backends/file/.libs/
Scanning backend libraries in backends/evolution/.libs/
Scanning backend libraries in backends/sqlite/.libs/
I think for end users it would be more useful to print the backends which were
really loaded. Congwu, can you change this for 0.9.1?
Note that I fixed a memory handling problem in SyncSourceBackendsInfo/Debug()
and turned the functions into static methods of SyncSource, like the related
createSource() method.
I don't think we have a version number for backends. If we had, this should
also go into this output. In 1.0 perhaps?
--
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