[SyncEvolution] single source for documentation (MBC #690)
by Patrick Ohly
Hello!
Everyone, I'm updating the documentation. Feedback please - I'm not
doing this for myself ;-)
Mike, I have a question about Drupal - see last paragraph.
Quoting http://bugs.meego.com/show_bug.cgi?id=690:
Keeping separate chunks of documentation in sync is an ongoing effort. Perhaps
we can simplify that task by keeping a single set of source files and generate
all other documentation from it automatically.
The documentation that would be nice to have is:
* README: plain text, the file that is currently maintained in git
* man pages for syncevolution, synccompare, sync-ui: doesn't exist at the moment
* the "Usage" page on syncevolution.org for the command line
As a first step (BMO#4633) the docs which have already diverged need to be
merged again. Then we need a single source format and corresponding make rules
which will generate the rest.
Today I look into this issue a bit more seriously. Originally, I
suggested Perl POD as that shared format, primarily because it is old
and typically installed on build systems.
But I never really liked the format. reStructuredText seems so much
nicer, so I did some more experiments with it and rst2man (in
python-docutils >= 0.6 (?)).
I was pleasantly surprised how easy it was to copy text from the README
into a README.rst. Very little changes were necessary to the markup. For
the most part, README.rst can still be read like a normal text, one of
the big strengths of rST. Question: should I strip the suffix when
preparing a release (install as README), replace with .txt (install as
README.txt) or leave it as it is?
The advantage of .rst is that Emacs and other tools (GNOME) recognize
the format. The disadvantage is that it might not always be recognized,
thus forcing to select a plain text reader.
The only part where markup is non-intuitive are some extra :: colons to
get the following text marked as a literal block and quoting a hyphen
where it was mistaken for something else:
\--migrate
In older SyncEvolution releases a different layout of configuration files
was used. ...
I find good enough to simply replace README with README.rst, without
doing any modifications to it.
The other change that I made is to reorganize the content so that it is
more like a reference man page. First, this minimizes the overlap with
instructions found elsewhere on syncevolution.org. Second, it was an
incentive to document some aspects (environment variables!) which were
not documented before.
Attached is a copy. What do you think about these changes? Any spelling
mistakes, unclear statements, etc.?
The conversion to man format works fine. Because rst2man is not always
installed, the man page would be optional. I'm attaching the man page
(syncevolution.1) and a rendered output (without escape codes, use "man
-l syncevolution.1" in a terminal if you want bold and underlined text).
Conversion to HTML also works and the result can be copied almost
verbatim into Drupal with "Full HTML" as format:
http://syncevolution.org/wiki/main-page
The goal is to replace the "Usage" page
(http://syncevolution.org/documentation/syncevolution-usage) with this
rendered man page.
"Copied almost verbatim" because that format differs from HTML in one
aspect: line breaks inside a paragraph are turned into a <br/>. I find
that inconvenient, because it also forces me to remove line breaks from
my announcement emails when I copy/paste them into Drupal. To me, it
also seems to deviate from normal Markdown syntax which normally uses
extra whitespace at the end of a line to insert <br/>
(http://daringfireball.net/projects/markdown/syntax#p).
Mike, is this a Drupal-specific extension? Can it be turned off?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
11 years, 11 months
[SyncEvolution] Request: Install D-Bus interface XML files
by Sascha Peilicke
Hi,
it would be great of the D-Bus interface XML files would be installed into
/usr/share/dbus-1/interfaces (or to whatever directory that is configured).
The KDE frontend is using them to generate Qt classes directly from the
interface definition rather than by tinkering with the glib-centric syncevo-
dbus-* headers. Currently we simply copy those XML files from the Git source.
--
Sascha Peilicke
http://saschpe.wordpress.com
11 years, 11 months
[SyncEvolution] Regarding Sync UI
by Dinesh
Hi all,
Just today, i stumbled found a feature of obexftp,
obexftp -X -b $MyN70, which gives us a lot of details on the features of the
phone offers:
['00:1D:6E:04:79:E2']
<?xml version="1.0" ?>
<!-- OBEX Capability Object -->
<!DOCTYPE Capability SYSTEM "obex-capability.dtd">
<Capability Version="1.0">
<General>
<Manufacturer>Nokia</Manufacturer>
<Model>RM-84</Model>
<SN>xxxxxxxxxxxxxxxxxxxx</SN>
<SW Version="V 5.0705.3.0.1" Date="20070130T000000Z"/>
<Language>en</Language>
<Memory>
<MemType>DEV</MemType>
<Location>C:\</Location>
<Free>15252992</Free>
<Used>4630016</Used>
<FileNLen>256</FileNLen>
</Memory>
<Memory>
<MemType>MMC</MemType>
<Location>E:\</Location>
<Free>717357056</Free>
<Used>309837824</Used>
<FileNLen>256</FileNLen>
</Memory>
</General>
<Service>
<Name>SyncML</Name>
<UUID>SYNCML-SYNC</UUID>
<Version>1.1</Version>
<Object>
<Type>application/vnd.syncml+wbxml</Type>
</Object>
</Service>
<Service>
<Name>PCCS</Name>
<UUID>F9EC7BC4-953c-11d2-984E-525400DC9E09</UUID>
<Version>1.0</Version>
<Ext>
<XNam>Backup</XNam>
<XVal>File=C:\System\backup.xml</XVal>
</Ext>
</Service>
<Service>
<Name>PCSuite-Settings</Name>
<Version>1.0</Version>
<Ext>
<XNam>SuiteConf</XNam>
<XVal>File=C:\System\SuiteConf.xml</XVal>
</Ext>
</Service>
<Service>
<Name>Multimedia Messages</Name>
<UUID>SYNCML-SYNC</UUID>
<Version>1.0</Version>
<Object>
<Type>application/vnd.wap.mms-message</Type>
<Name-Ext>mms</Name-Ext>
</Object>
<Ext>
<XNam>SyncProfile</XNam>
<XVal>HostAddress=mms</XVal>
<XVal>Database=mms</XVal>
</Ext>
<Ext>
<XNam>Databases</XNam>
<XVal>Drafts=./4097/4100/</XVal>
<XVal>Inbox=./4097/4098/</XVal>
<XVal>Outbox=./4097/4099/</XVal>
<XVal>SentItems=./4097/4101/</XVal>
</Ext>
</Service>
<Service>
<Name>Text Messages</Name>
<UUID>SYNCML-SYNC</UUID>
<Version>1.7.0</Version>
<Object>
<Type>text/x-vMessage</Type>
<Name-Ext>sms</Name-Ext>
</Object>
<Ext>
<XNam>SyncProfile</XNam>
<XVal>HostAddress=sms</XVal>
<XVal>Database=sms</XVal>
</Ext>
<Ext>
<XNam>Databases</XNam>
<XVal>Drafts=./4097/4100/</XVal>
<XVal>Inbox=./4097/4098/</XVal>
<XVal>Outbox=./4097/4099/</XVal>
<XVal>SentItems=./4097/4101/</XVal>
</Ext>
</Service>
<Service>
<Name>PC Suite support</Name>
<Version>1.7.0</Version>
</Service>
<Service>
<Name>Folder-Browsing</Name>
<UUID>F9EC7BC4-953c-11d2-984E-525400DC9E09</UUID>
<Version>1.0</Version>
<Object>
<Type>x-obex/folder-listing</Type>
</Object>
<Ext>
<XNam>Images</XNam>
<XVal>Folder=C:\Nokia\Images\</XVal>
<XVal>MemType=DEV</XVal>
</Ext>
...................
</Capability>
and from the syncevolution's website, this is what i have gotten,
"The sync-ui then lists paired devices with SyncML support and offers to
configure them using one of the available device configuration templates. It
tries to find a suitable template based on the name given to the device,
which only works well if that name includes the model (for example, "John
Doe's N85")."
so shouldn't the obexftp tool be useful for us in easily configuring our
phone?
I have tested it only on a few nokia phones.. so i couldn't yet conclude
more information about this..
right now, here is the status:
Nokia 6600 (S60 OS 7) : the tool doesnt work
Nokia N70 (S60 OS 8.1): it works
Nokia E63 (S60 v3) : it works the same way it does for N70
(the settings however would stay same for all S60 models of the same version
though. so i also can't conclude how useful this service can be.)
Cheers
Dinesh
11 years, 11 months
[SyncEvolution] Syncing N900 with MDaemon SyncML service
by Taomyn
Hi,
I've been struggling to get my N900 to sync against my MDaemon server and I'm
hoping someone here may be able to help. FYI - I've tested my server by syncing
it with Thunderbird using the Funambol add-on for TB and it works just fine.
My initial problem on the N900 is that SyncEvolution was not accepting my SSL
certificate, complaining that it was unable to verify it. I'm not sure why as
the rest of the phone accepts it, notably MicroB and Modest, plus Thunderbird on
my PC has no issue. However, I did work around this by editing the config.ini
file and telling it to ignore the SSL verification.
Now that I'm able to connect I'm unable to sync at all, and SyncEvolution simply
drops the connection. The log says at one point:
# [2010-06-01 13:29:53.950] =================> Finished processing incoming
message #1 (final), request=0
# [2010-06-01 13:29:53.950] MessageEnded finishes : new outgoing state='sync',
new incoming state='sync', NeedToAnswer
# [2010-06-01 13:29:53.951] Local Datastore 'todo': State=sync_mode_stable, SLOW
sync, from client only
# [2010-06-01 13:29:53.951] Local Datastore 'memo': State=sync_mode_stable, SLOW
sync, from client only
# [2010-06-01 13:29:53.951] Local Datastore 'addressbook':
State=sync_mode_stable, SLOW sync, from client only
# [2010-06-01 13:29:53.952] Local Datastore 'calendar': State=sync_mode_stable,
SLOW sync, from client only
# [2010-06-01 13:29:53.952] No common datastore formats -> cannot sync (415)
#
+
–
[2010-06-01 13:29:53.953] 'DSAbort' - Aborting datastore sync,
abortStatusCode=415, localProblem=yes, resumable=no [--][++] [->end] [->enclosin
g]
*
+
–
[2010-06-01 13:29:53.953] 'SaveSuspendState' - Saving state for
suspend/resume [--][++] [->end] [->enclosing]
o
+
–
[2010-06-01 13:29:53.954] 'SaveAdminData' - Saving changelog, target
and map info [--][++] [->end] [->enclosing]
–[2010-06-01 13:29:53.957] End of 'SaveAdminData' [->top] [->enclosing]
–[2010-06-01 13:29:53.957] End of 'SaveSuspendState' [->top] [->enclosing]
* [2010-06-01 13:29:53.958] *************** Warning: Datastore flagged
aborted (after 0 sec. request processing, 2 sec. total) with LOCAL Status 415
–[2010-06-01 13:29:53.958] End of 'DSAbort' [->top] [->enclosing]
#
+
–
[2010-06-01 13:29:53.959] 'SessionAbort' - Aborting Session, Status=415,
ProblemSource=LOCAL [--][++] [->end] [->enclosing]
* [2010-06-01 13:29:53.959] WARNING: Aborting Session with Reason Status 415
(LOCAL problem) ***
* [2010-06-01 13:29:53.960] --------------- Ignoring all commands in this
message (after 0 sec. request processing, 2 sec. total) with Status 514 (0=none)
from here on
There is nothing on the server to say there is a problem, all seems to be well
as far as it can tell.
I'll also paste this in case it helps:
[2010-06-01 13:29:53.783] 'DevInf_Analyze' - Analyzing remote devInf [--][++]
[->end] [->enclosing]
* [2010-06-01 13:29:53.784] Device ID='ALT-N WorldClient', Type='server',
Model='ALT-N WorldClient SyncML Server'
* [2010-06-01 13:29:53.784] Manufacturer='ALT-N Technologies', OEM='ALT-N
Technologies'
* [2010-06-01 13:29:53.785] Softwarevers='11.0.2', Firmwarevers='',
Hardwarevers=''
* [2010-06-01 13:29:53.786] SyncML Version: SyncML/1.2
* [2010-06-01 13:29:53.786] SyncML capability flags: wantsNOC=Yes,
canHandleUTC=Yes, supportsLargeObjs=Yes
*
+
–
[2010-06-01 13:29:53.786] 'RemoteRules' - Checking for remote rules
[--][++] [->end] [->enclosing]
–[2010-06-01 13:29:53.787] End of 'RemoteRules' [->top] [->enclosing]
* [2010-06-01 13:29:53.787] Summary of all behaviour options (eventually set
by remote rule)
* [2010-06-01 13:29:53.788] - Remote Description : ALT-N Technologies ALT-N
WorldClient SyncML Server
* [2010-06-01 13:29:53.788] - Legacy mode : No
* [2010-06-01 13:29:53.788] - Lenient mode : No
* [2010-06-01 13:29:53.789] - Limited Field Lengths : No
* [2010-06-01 13:29:53.789] - Do not send empty props : No
* [2010-06-01 13:29:53.789] - Quote 8bit content : No
* [2010-06-01 13:29:53.790] - Prevent Content Folding : Yes
* [2010-06-01 13:29:53.810] - No replace in slowsync : No
* [2010-06-01 13:29:53.811] - Treat remote TZ as local : No
* [2010-06-01 13:29:53.811] - Treat remote TZ as UTC : No
* [2010-06-01 13:29:53.811] - Use 23:59:59 end dates : Yes
* [2010-06-01 13:29:53.812] - Ignore field maxSize : No
* [2010-06-01 13:29:53.812] - Ignore CTCap : No
* [2010-06-01 13:29:53.812] - send DS path in devInf : Yes
* [2010-06-01 13:29:53.813] - send DS CGI in devInf : Yes
* [2010-06-01 13:29:53.813] - Update Client in slowsync : No
* [2010-06-01 13:29:53.813] - Update Server in slowsync : No
* [2010-06-01 13:29:53.814] - Allow message retries : Yes
* [2010-06-01 13:29:53.814] - Strict SyncML exec order : Yes
* [2010-06-01 13:29:53.814] - Treat copy like add : No
* [2010-06-01 13:29:53.815] - Complete From-Client-Only : No
* [2010-06-01 13:29:53.815] - Remote can handle UTC : Yes
* [2010-06-01 13:29:53.815] - Max Request time [sec] : 0
* [2010-06-01 13:29:53.816] - Content output charset : UTF-8
*
+
–
[2010-06-01 13:29:53.816] 'RemoteDatastores' - Analyzing remote datastores
[--][++] [->end] [->enclosing]
o
+
–
[2010-06-01 13:29:53.818] 'RemoteDSDevInf' - Registering remote
Datastore from devInf [--][++] [->end] [->enclosing]
+ [2010-06-01 13:29:53.820] Datastore DevInf does not specify
MaxGUIDSize -> using default
+ [2010-06-01 13:29:53.824] Remote Datastore Name='./contacts',
DisplayName='contacts', MaxGUIDSize=0
+ [2010-06-01 13:29:53.825] Preferred Rx='text/x-vcard' version
'2.1', preferred Tx='text/x-vcard' version '2.1'
+
+
–
[2010-06-01 13:29:53.825] 'RemoteTypes' - Analyzing remote
types listed in datastore level CTCap [--][++] [->end] [->enclosing]
#
+
–
[2010-06-01 13:29:53.826] 'RemoteCTCap' - Registering
remote Type/Version from >=DS 1.2 style CTCap, type=text/x-vcard, version=2.1
[--][++] [->end] [->enclosing]
* [2010-06-01 13:29:53.827] Registered Type
'text/x-vcard' Version='2.1', implemented by local type vCard21, related to
remote datastore './contacts'
–[2010-06-01 13:29:53.828] End of 'RemoteCTCap' [->top]
[->enclosing]
#
+
–
[2010-06-01 13:29:53.828] 'RemoteCTCap' - Registering
remote Type/Version from >=DS 1.2 style CTCap, type=text/vcard, version=3.0
[--][++] [->end] [->enclosing]
* [2010-06-01 13:29:53.829] Registered Type
'text/vcard' Version='3.0', implemented by local type vCard30, related to remote
datastore './contacts'
–[2010-06-01 13:29:53.830] End of 'RemoteCTCap' [->top]
[->enclosing]
–[2010-06-01 13:29:53.830] End of 'RemoteTypes' [->top]
[->enclosing]
–[2010-06-01 13:29:53.830] End of 'RemoteDSDevInf' [->top] [->enclosing]
o
+
–
[2010-06-01 13:29:53.831] 'RemoteDSDevInf' - Registering remote
Datastore from devInf [--][++] [->end] [->enclosing]
+ [2010-06-01 13:29:53.831] Datastore DevInf does not specify
MaxGUIDSize -> using default
+ [2010-06-01 13:29:53.832] Remote Datastore Name='./calendar',
DisplayName='calendar', MaxGUIDSize=0
+ [2010-06-01 13:29:53.832] Preferred Rx='text/x-vcalendar'
version '1.0', preferred Tx='text/x-vcalendar' version '1.0'
+
+
–
[2010-06-01 13:29:53.832] 'RemoteTypes' - Analyzing remote
types listed in datastore level CTCap [--][++] [->end] [->enclosing]
#
+
–
[2010-06-01 13:29:53.833] 'RemoteCTCap' - Registering
remote Type/Version from >=DS 1.2 style CTCap, type=text/x-vcalendar,
version=1.0 [--][++] [->end] [->enclosing]
* [2010-06-01 13:29:53.833] Registered Type
'text/x-vcalendar' Version='1.0', NOT implemented, related to remote datastore
'./calendar'
–[2010-06-01 13:29:53.834] End of 'RemoteCTCap' [->top]
[->enclosing]
–[2010-06-01 13:29:53.834] End of 'RemoteTypes' [->top]
[->enclosing]
–[2010-06-01 13:29:53.835] End of 'RemoteDSDevInf' [->top] [->enclosing]
o
+
–
[2010-06-01 13:29:53.835] 'RemoteDSDevInf' - Registering remote
Datastore from devInf [--][++] [->end] [->enclosing]
+ [2010-06-01 13:29:53.835] Datastore DevInf does not specify
MaxGUIDSize -> using default
+ [2010-06-01 13:29:53.836] Remote Datastore Name='./tasks',
DisplayName='tasks', MaxGUIDSize=0
+ [2010-06-01 13:29:53.836] Preferred Rx='text/x-vcalendar'
version '1.0', preferred Tx='text/x-vcalendar' version '1.0'
+
+
–
[2010-06-01 13:29:53.837] 'RemoteTypes' - Analyzing remote
types listed in datastore level CTCap [--][++] [->end] [->enclosing]
#
+
–
[2010-06-01 13:29:53.837] 'RemoteCTCap' - Registering
remote Type/Version from >=DS 1.2 style CTCap, type=text/x-vcalendar,
version=1.0 [--][++] [->end] [->enclosing]
* [2010-06-01 13:29:53.838] Registered Type
'text/x-vcalendar' Version='1.0', NOT implemented, related to remote datastore
'./tasks'
–[2010-06-01 13:29:53.838] End of 'RemoteCTCap' [->top]
[->enclosing]
–[2010-06-01 13:29:53.838] End of 'RemoteTypes' [->top]
[->enclosing]
–[2010-06-01 13:29:53.839] End of 'RemoteDSDevInf' [->top] [->enclosing]
o
+
–
[2010-06-01 13:29:53.839] 'RemoteDSDevInf' - Registering remote
Datastore from devInf [--][++] [->end] [->enclosing]
+ [2010-06-01 13:29:53.839] Datastore DevInf does not specify
MaxGUIDSize -> using default
+ [2010-06-01 13:29:53.840] Remote Datastore Name='./notes',
DisplayName='notes', MaxGUIDSize=0
+ [2010-06-01 13:29:53.840] Preferred Rx='text/plain' version
'1.0', preferred Tx='text/plain' version '1.0'
+
+
–
[2010-06-01 13:29:53.840] 'RemoteTypes' - Analyzing remote
types listed in datastore level CTCap [--][++] [->end] [->enclosing]
#
+
–
[2010-06-01 13:29:53.841] 'RemoteCTCap' - Registering
remote Type/Version from >=DS 1.2 style CTCap, type=text/x-vnote, version=1.1
[--][++] [->end] [->enclosing]
* [2010-06-01 13:29:53.842] Registered Type
'text/x-vnote' Version='1.1', NOT implemented, related to remote datastore './no
tes'
–[2010-06-01 13:29:53.842] End of 'RemoteCTCap' [->top]
[->enclosing]
–[2010-06-01 13:29:53.842] End of 'RemoteTypes' [->top]
[->enclosing]
+ [2010-06-01 13:29:53.843] Registered Type 'text/plain'
Version='1.0', implemented by local type note10, related to remote datastore
'./notes'
–[2010-06-01 13:29:53.843] End of 'RemoteDSDevInf' [->top] [->enclosing]
–[2010-06-01 13:29:53.844] End of 'RemoteDatastores' [->top] [->enclosing]
–[2010-06-01 13:29:53.844] End of 'DevInf_Analyze' [->top] [->enclosing]
Can anyone point me in the right direction?
Many thanks,
Taomyn
11 years, 11 months
