gmane.comp.misc.opensync.devel

Re: evo3 plugin and API changes in evo-d-s 3.6

Chris Frey — 2013-01-08T02:32:12

Thanks Mark!  Sorry for the delay in processing.

I've applied it to the evolution3 git repo, and it should percolate to
binary-meta in due time.

- Chris


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512

evo3 plugin and API changes in evo-d-s 3.6

Mark Ellis — 2012-12-30T14:56:10

Hi Chris

Another patch for the evo3 plugin.

Evolution Data Server 3.6 quietly lost the functions previously used to
obtain data sources, and introduced ESourceRegistry.

This one had me scratching my head for a while .....

Mark

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: more news from python land

Mark Ellis — 2012-09-07T13:28:13

I just realized I was being a bit daft there. I didn't like the
commented out destructor code because of what would happen if the
userdata wasn't a python object, but of course it has to be a python
object, because there is no way to pass in anything else !

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: more news from python land

Chris Frey — 2012-09-06T18:45:38

I think I've solved it by causing the ObjTypeSink wrapper to always
own the callback_obj.  I uncommented the destructor code, and the
added code to set_callback_obj() to free any old pointers before accepting
the new one.

I think that should be sufficient.

- Chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: evo3 plugin patch

Chris Frey — 2012-09-06T18:19:12

No problem.   I'd rather have the patch in any usable format than
slow you down. :-)

- Chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: evo3 plugin patch

Mark Ellis — 2012-09-06T08:59:54

Don't see why, e_cal_client_new_default() returns ECalClient in the same
way as e_cal_client_new() ?0


synce is in svn, I only know the bare basics of git, so anything I do on
opensync is on a checked out git repo, but I just treat it as a local
source tree against a clean copy. I find I have enough trouble keeping
up with support library changes, without extra VCS knowledge as well :)

Mark

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: more news from python land

Mark Ellis — 2012-09-06T08:49:31


Yes, I don't like that one either, it's a lovely circular reference
between the sink and the callback object isn't it. The only way I can
see around it is not to reference the callback object in the sink
constructor, which may be valid because sinks in the other plugins don't
reference their userdata, they rely on the plugin to do that. It'll need
a bit of looking into though. I don't think it's necessarily a worry at
the moment, since osynctool is a one shot sync, but it definitely isn't
very neat.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https:

Re: more news from python land

Chris Frey — 2012-09-05T21:38:46

Thanks!  I was away last week, so I didn't get to your patches
until today.



I'm a little concerned with the built-in leak here:

--- a/wrapper/opensync-plugin.i
+++ b/wrapper/opensync-plugin.i
< at >< at > -533,6 +533,13 < at >< at > typedef struct {} ObjTypeSink;
        }
         */
 
+       void set_callback_obj(PyObject *callback_obj = NULL) {
+               /* set userdata pointer to supplied python wrapper object */
+               if (callback_obj) {
+                       Py_INCREF(callback_obj);
+                       osync_objtype_sink_set_userdata(self, callback_obj);
+               }
+       }


I don't see any easy way to avoid that one.  Any object passed into
set_callback_obj() will never die in Python.  And this includes the
callback class itself from the user's sample.py code, since it is
referenced indirectly in the ObjTypeSinkCallbacks constructor.

If it was just an internal temporary object, I probably wouldn't mind
so much, but for a user's class, they probably will be expecting it
to get cleaned

Re: evo3 plugin patch

Chris Frey — 2012-09-05T20:49:44

Thanks!  I've applied all of it, but I have a question about:



--- a/src/evolution3_ecal.c
+++ b/src/evolution3_ecal.c
< at >< at > -69,11 +69,6 < at >< at > ECalClient *evo3_ecal_open_cal(const char *path, ECalClientSourceType source_typ
                        osync_error_set(error, OSYNC_ERROR_GENERIC, "Failed to create new calendar");
                        goto error;
                }
-
-               if(!e_client_open_sync(E_CLIENT(calendar), FALSE, NULL, &gerror)) {
-                       osync_error_set(error, OSYNC_ERROR_GENERIC, "Failed to open calendar: %s", gerror ? gerror->message : "None");
-                       goto error_free_event;
-               }
        } 
        else {
                osync_trace(TRACE_INTERNAL, "Opening default calendar\n");
< at >< at > -82,6 +77,12 < at >< at > ECalClient *evo3_ecal_open_cal(const char *path, ECalClientSourceType source_typ
                        goto error_free_event;
                }
        }
+
+       if(!e_client_open_sync(E_CLIENT(calendar), FALSE, NULL, &gerror)) {
+

evo3 plugin patch

Mark Ellis — 2012-09-05T16:15:01

Hi Chris

Attached a patch for the evo3 plugin.

Rename a few occurrences of evo2 to evo3.

Change names of commit funcs from _modify to _commit for consistency.

Move use of e_client_open_sync() for ecal to cover default uri as well
as specified uri's.

Check for failure retrieving icalcomponent from calendar in get_changes.

Don't unref component's explicitly in get_changes for ecal, this is done
by e_client_util_free_object_slist().

Unref contact format and addressbook in free_env().

Mark

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https://lists.s

more news from python land

Mark Ellis — 2012-08-29T15:45:57

Hi

I've made some good steps with getting the python plugin work how its
should do, at least I hope it's how it should be :)

I think i've figured out this 'main sink' business, it's an objtype
neutral sink that is supposed to deal with anything that is common for
all objtype sinks, and appears to be potentially very useful but also
entirely optional. It also has nothing to do with what we return from
the python initialize func, that problem appeared to be a ref counting
issue that was inadvertantly solved by returning the sink object.

So, two patches attached. The first, to the library wrapper, implements
a function to set the callback data for an already existing sink object.
It also modifies the base sink callback object constructor to accept
either an existing sink, or an objtype to create a new sink. It should
also accept no objtype to create a main sink, but I haven't actually
tested anything with main sinks in python yet.

The second patch, to the python plugin, improves on some error
reporting, sav

Re: problem with file-sync format ?

Chris Frey — 2012-08-24T18:49:10

Thanks!  Applied.

- Chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: problem with file-sync format ?

Mark Ellis — 2012-08-24T13:54:42

I think i've found it, patch attached.

Firstly, changed the name from _fold_lines  to _unfold_lines.

The problem was that =\r\n was being passed through unchanged when the
line is marked QUOTED-PRINTABLE, when in fact it should be a 'soft' line
break. The \r\n should only be left in when not preceeded by the =. It
worked with unix new lines because it's only one character.

Mark

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: problem with file-sync format ?

Chris Frey — 2012-08-23T21:29:43

Ahh... thanks.

Looks like it has something to do with Unix or DOS line endings.
If I save your attached file in vim with set ff=dos, I get the truncated
version of XML.  If I use set ff=unix, I get the full thing.

Off to figure out why...

- Chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: problem with file-sync format ?

Mark Ellis — 2012-08-23T21:07:21

Hi Chris

On Thu, 2012-08-23 at 17:44 +0200, Chris Frey wrote:

I mean in the vcard attachment, which is the output from evo->file sync,
the wrap has no leading space, which I believe is required in vcard.
Yes, in the xml, it's irrelevant. So I think that's a problem with vcard
output, possibly in vformat.c, vformat_to_string().

Then when that vcard goes into the file->synce sync, you get the above
xml. Note the AddressLabel element actually contains some of the
following text from the vcard line, in this case the start of the EMAIL
tag, so looks like something wrong with converting the other way as
well, possibly in vformat.c, _fold_lines(), a rather unfortunately named
function because it seems to be there to unfold lines :)



No, the errors are all in the content.


file sync's are default config except for the path, evo2 is default,
synce is NO_CONFIG.

Next step i'm going to try and grab the vcard fed from evo to file in
the first sync from a trace and see what happens to it in isolation.

-----------

Re: problem with file-sync format ?

Chris Frey — 2012-08-23T15:44:27

The XML doesn't have the vformat restrictions that vformat itself does,
so I believe that the non-space wrap is correct here.  The field is
surrounded by <Content></Content>, so whatever is inside can be rather
free-flowing.



Here are my tests with the vconvert tool (from vformat format plugin):

[cdfrey build]$ cat test.xml 
<?xml version="1.0"?>
<contact>
  <Address Location="Home">
    <PostOfficeBox/>
    <ExtendedAddress/>
    <Street>4 York Road</Street>
    <Locality>Tonbridge</Locality>
    <Region>Kent</Region>
    <PostalCode>TN10 4QR</PostalCode>
    <Country/>
  </Address>
  <AddressLabel Location="Home">
    <Content>4 York Road
Tonbridge, Kent
TN10 4QREMAIL</Content>
  </AddressLabel>
</contact>


[cdfrey build]$ vconvert test.xml --to-vcard21
BEGIN:VCARD
VERSION:2.1
ADR;HOME:;;4 York Road;Tonbridge;Kent;TN10 4QR;
LABEL;ENCODING=QUOTED-PRINTABLE;HOME:4 York Road=0ATonbridge, Kent=0ATN10 4=
QREMAIL
END:VCARD


[cdfrey build]$ vconvert test.xml --to-vcard30
BEGIN:VCARD
VERSION:3.0
ADR;TYPE=HOM

problem with file-sync format ?

Mark Ellis — 2012-08-23T10:58:36

Hiya

In the course of bringing synce back into the fold, I've come across
something which seems to be in file-sync.

First the background to my process. I've a sync group of evo2-sync and
file-sync, to dump my contact list for testing. I then have another
group of file-sync and synce to test the synce side with no disruption.
The sync process completes, which is good !

Amongst my format problems, I have a number of contacts, only those that
contain a mailing address, that end up massively truncated, in fact only
containing the address. From a little investigation it looks like a
problem with the data coming from file-sync.

An example, the attached vcard is the result of the evo->file sync, to
feed into the next stage. It's attached rather than inline to preserve
the formatting.

And the following is what gets fed into the synce plugin.

<?xml version="1.0"?>
<contact>
  <Address Location="Home">
    <PostOfficeBox/>
    <ExtendedAddress/>
    <Street>4 York Road</Street>
    <Locality>Tonbridge</Locality>

Re: python wrapper and plugin

Chris Frey — 2012-08-20T19:03:30

Thanks!  Applied.

- Chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: python wrapper and plugin

Mark Ellis — 2012-08-20T10:30:19

Yep, it certainly does, thanks again.

Attached a couple of patches, fixes exception reporting from python and
thread state after initialisation.

Getting there now, the sync process completes with the synce plugin,
hurrah ! Some internal formatting problems still to sort, but there is
definitely light at the end of the tunnel.

Mark

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Opensync-devel mailing list
Opensync-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: python wrapper and plugin

Chris Frey — 2012-08-15T18:10:29

Ok, this has been implemented.  Read the commit message for details.

It works with "import dbus" now. :-)

- Chris


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: python wrapper and plugin

Chris Frey — 2012-08-14T21:00:52

Thanks.   I think we'll need to convert the python_module into a
OSYNC_START_TYPE_EXTERNAL type plugin, but which does not run as its
own plugin at all, only a helper.

Each python script would also be an external plugin, and be configured
by .xml file instead of using the get_sync_info() function callback.
The .xml file would reference the python_module program in the
<ExternalCommand> element.

See the docs/examples/plugins/src/external* files for an example.
I think we'd use something like this for the sample.py:

 <ExternalPlugin version="1">
  <Name>python-sample</Name>
  <LongName>Sample Python plugin</LongName>
  <Description>Longer description for the sample python plugin.</Description>
  <ExternalCommand>python_module sample.py %s</ExternalCommand>
 </ExternalPlugin>

This should give each python script module its own forked process space,
which might be a good idea.  Installing a python module would be a matter
of copying the .py script into the usual libopensync1/python-plugins/
directory, and an