[Bug 6378] New: automatic sync
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=6378
Summary: automatic sync
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
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
Release Milestone: Undecided
We want some form of automatic syncs in SyncEvolution 1.0. Probably something
based on polling will be good enough initially. This issue is just a reminder
that we need to discuss this in more detail. Eventually it'll depend on more
specific sub-problems, covering:
* starting a daemon to control the automatism
* detect errors which require user intervention
* notifications
--
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, 4 months
[Bug 1351] New: SyncEvolution code cleanup
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=1351
Summary: SyncEvolution code cleanup
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: trivial
Priority: Medium
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=3472
Description From pohly 2009-06-12 07:57:10 PST (-) [reply]
This issue is about several aspects of the SyncEvolution source code. It could
be cleaned up in several ways. All of these changes are not strictly necessary
(minor severity) but should be done at some point (priority 2).
SyncItem::setData() now exists in a variant which takes a std::string. Check
all calls of the form setData(str.c_str(), str.size()) and replace them with
setData(str).
ConfigNode has template methods for set/getProperty(). Some old code reads
strings and converts them instead of using the template methods. Change that
code.
Remove "using namespace std" and add "std::" wherever necessary.
All SyncEvolution symbols should be in their own namespace. I suggest SyncEvo.
I don't like that Emacs indents members of namespaces:
namespace SyncEvo {
int foo;
}
I suggest using some defines like G_BEGIN_DECLS and G_END_DECLS instead, in
particular in header files. Details to be discussed.
For macros we should use the SE_ prefix (not done consistently either!).
The word EvolutionSyncClient and EvolutionSyncSource come from the Funambol
SyncClient and SyncSource classes. Nowadays SyncEvolutionClient and
SyncEvolutionSource seem more natural. Rename the classes and the files?!
------- Comment #1 From pohly 2009-06-18 23:56:03 PST (-) [reply] -------
(In reply to comment #0)
> The word EvolutionSyncClient and EvolutionSyncSource come from the Funambol
> SyncClient and SyncSource classes. Nowadays SyncEvolutionClient and
> SyncEvolutionSource seem more natural. Rename the classes and the files?!
Perhaps abandon "SyncClient" entirely. At some point we will have a SyncML
server which is likely to be using the same class. "SyncEvolutionSession"?
------- Comment #2 From pohly 2009-07-20 06:41:40 PST (-) [reply] -------
Not all code compiles cleanly on all platforms: bug #4555
------- Comment #3 From pohly 2009-10-05 06:08:55 PST (-) [reply] -------
The externally visible part is done for 0.9.1. Rescheduling the rest for later.
(In reply to comment #0)
> SyncItem::setData() now exists in a variant which takes a std::string. Check
> all calls of the form setData(str.c_str(), str.size()) and replace them with
> setData(str).
TBD.
> ConfigNode has template methods for set/getProperty(). Some old code reads
> strings and converts them instead of using the template methods. Change that
> code.
TDB.
> Remove "using namespace std" and add "std::" wherever necessary.
TBD.
> All SyncEvolution symbols should be in their own namespace. I suggest SyncEvo.
> I don't like that Emacs indents members of namespaces:
> namespace SyncEvo {
> int foo;
> }
>
> I suggest using some defines like G_BEGIN_DECLS and G_END_DECLS instead, in
> particular in header files.
Done, using SE_BEGIN/END_CXX.
> For macros we should use the SE_ prefix (not done consistently either!).
TBD.
> The word EvolutionSyncClient and EvolutionSyncSource come from the Funambol
> SyncClient and SyncSource classes. Nowadays SyncEvolutionClient and
> SyncEvolutionSource seem more natural. Rename the classes and the files?!
Done:
commit 71fbf32c941ab17355483028a6f529354e58e18e
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Oct 5 14:49:32 2009 +0200
files and classes renamed, include statements cleaned up
The intention is to get rid of the historic and inconsistent
naming of some classes and their corresponding files:
* EvolutionSyncClient = class derived from Funambol's SyncClient,
* SyncEvolutionConfig = SyncEvolution's config
With the strict 'namespace SyncEvo' and the syncevo/ path prefix for
most header files it is no longer necessary to have "SyncEvolution" or
"Evolution" in the names. This patch thus renames as follows:
EvolutionSyncClient => SyncContext
EvolutionSmartPtr => SmartPtr
SyncEvolutionCmdline => Cmdline
SyncEvolutionConfig => SyncConfig
SyncEvolutionUtil => util
The former EvolutionSyncClient always had a role that went beyond just
running a sync, for example it also provided config access. With the
upcoming server support it also won't be just a client. Thus the new
name "SyncContext".
The 'syncevo/' prefix is used throughout the code now.
removed whenever the prefix made it clear that the file belongs
to SyncEvolution. This helps finding incorrect include paths.
Quotes should be used exclusively for SyncEvolution files which don't
have a specific prefix yet (test.h, config.h) to help identifying
them.
--
Configure bugmail: http://bugs.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, 4 months
[Bug 1349] New: HTTP AUTH
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=1349
Summary: HTTP AUTH
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: normal
Priority: Low
Component: SyncML
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-syncml-bugs(a)meego.bugs
Estimated Hours: 0.0
This is from http://bugzilla.moblin.org/show_bug.cgi?id=2429
Description From pohly 2009-05-14 12:22:55 PST (-) [reply]
Copied from
https://sourceforge.net/tracker/?func=detail&aid=2056162&group_id=146288&...
Some SyncML servers require authentication via HTTP AUTH. I don't remember for
which server, but it was based on a user request.
Currently there are no setting for such HTTP AUTH credentials. Need to be added
(SyncEvolutionConfig.cpp) and hooked up with the HTTP transports (both libcurl
and libsoup).
------- Comment #1 From ruskie 2010-01-13 10:59:13 PST (-) [reply] -------
I have such a syncML server setup. In case there is need I can setup a
developer account to test this.
In my case it's reguralh http server with horde being http authed and being the
syncml server.
------- Comment #2 From pohly 2010-01-18 03:39:31 PST (-) [reply] -------
(In reply to comment #1)
> I have such a syncML server setup. In case there is need I can setup a
> developer account to test this.
Thanks for the offer. But I think we can test this more easily by extending our
own syncevo-http-server.py to offer HTTP AUTH as an optional feature.
> In my case it's reguralh http server with horde being http authed and being the
> syncml server.
Do you know whether the Horde server still requires a valid username/password
at the SyncML level? Is it the same as the HTTP AUTH password?
I am asking because the sync-UI would only be able to set one username/password
pair, the one for SyncML. We could add separate http-username/passsword
properties and define them so that setting them is only necessary when they
differ from the normal SyncML credentials. If unset and the HTTP server ask for
authorization, the SyncML credentials could be used.
------- Comment #3 From ruskie 2010-01-18 03:58:25 PST (-) [reply] -------
(In reply to comment #2)
> > In my case it's reguralh http server with horde being http authed and being the
> > syncml server.
>
> Do you know whether the Horde server still requires a valid username/password
> at the SyncML level? Is it the same as the HTTP AUTH password?
It only requires the HTTP AUTH password. That's how it's configured. You can
configure it in so many different ways. But most usually use their own login
interface and the syncml layer requests the auth itself.
But with HTTP AUTH it only checks if you are authed and if you are it will
fulfill the request.
> I am asking because the sync-UI would only be able to set one username/password
> pair, the one for SyncML. We could add separate http-username/passsword
> properties and define them so that setting them is only necessary when they
> differ from the normal SyncML credentials. If unset and the HTTP server ask for
> authorization, the SyncML credentials could be used.
curl -k https://my.domain.tld/rpc.php
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>401 - Unauthorized</title>
</head>
<body>
<h1>401 - Unauthorized</h1>
</body>
</html>
curl --user 'username:password' -k https://my.domain.tld/rpc.php
<?xml version="1.0"?><disco:discovery
xmlns:disco="http://schemas.xmlsoap.org/disco/"
xmlns:scl="http://schemas.xmlsoap.org/disco/scl/">
<scl:contractRef ref="https://my.domain.tld/rpc.php?wsdl" />
</disco:discovery>
Hope that helps.
--
Configure bugmail: http://bugs.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, 4 months
[Bug 1197] syncevo-phone-config: broken Python syntax, error messages
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=1197
--- Comment #18 from pohly <patrick.ohly(a)intel.com> 2010-04-26 09:30:06 PDT ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #8)
> > > Some ideas:
> > > 1. don't repeat tests with different data types that all get mapped
> > > to the same SAN: if text/vcard fails, so will text/x-vcard
> > > 2. once we found a valid SyncML version and host identifier, skip
> > > testing with any combination which involved invalid parameters -
> > > great, we already do that!
> > >
> > > Hmm, my statement in 1. isn't quite correct: once sending the SAN succeeds, the
> > > type does matter because it influences our DevInf sent to the device. Actually,
> > > the forced types are missing in the testing.
> >
> > Contrary to my expectations, "type = text/calendar" fails with the K750 while
> > "type = text/x-vcalendar" works. Need to check.
>
> Still need to check this
Done. Congwu, do you agree that there was a typo in the code?
commit b1b29f54a2186b6ee9f23d3b8ecf81dee6ea59f7
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Apr 26 18:25:44 2010 +0200
SAN message: typo fix in text/calendar => text/x-vcalendar mapping (MBC
#1197)
The Sony Ericsson K750i accepts "text/x-vcalendar" as type in the SAN
message,
but not "text/calendar". We had code which was supposed to map to the older
type, but due to a typo ended up sending "text/x-calendar", which is
rejected.
Fixed.
> and add forced types to the testing.
TBD.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 4 months