[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.
10 years, 9 months
[Bug 8933] New: sync-ui segmentation fault on ubuntu 9.10 64-bit
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8933
Summary: sync-ui segmentation fault on ubuntu 9.10 64-bit
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Other
Status: NEW
Severity: normal
Priority: Undecided
Component: GTK UI
AssignedTo: jku(a)linux.intel.com
ReportedBy: bobx(a)gmx.ch
QAContact: yanshuang.zheng(a)intel.com
CC: syncevolution(a)lists.intel.com
Hi
I installed sync-ui, did run it first time, configured it and everything
worked. Then I closed it and reopend it and it crashed immediately with a
Segmentation fault.
Could you help??
thanks
easybeat
--
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.
10 years, 10 months
[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.
10 years, 10 months
[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.
10 years, 10 months
[Bug 9216] New: Implement GetConfigs dbus call for direct sync
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=9216
Summary: Implement GetConfigs dbus call for direct sync
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: major
Priority: Undecided
Component: SyncEvolution
AssignedTo: yongsheng.zhu(a)intel.com
ReportedBy: congwu.chen(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: syncevolution(a)lists.intel.com
As we discussed in bugzilla 7089, GetConfigs need to be changed accordingly to
support direct sync and use the new Template Configuration api.
In particular, we have to:
1) Listen on Bluez to get a list of paired devices
2) In GetConfigs (true), we have to query against the underlying template
system via the device name we got from Bluez and create a list of templates for
each device, the templates need be stored per client session.
3) A later GetConfig in the same session would get the template created in the
previous step.
It is nice if we could detect correctly if the peer is a SyncEvolution based
implementation, thus we query against the template system via "SyncEvolution"
instead of the device name.
--
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.
10 years, 10 months
[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.
10 years, 10 months
[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.
10 years, 10 months
[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.
10 years, 10 months
[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.
10 years, 10 months