[strongSwan-dev] Python vici library

[Björn Schuberg]

Hi Martin,

Thanks for your update. It looks a bit complicated to me, but I've tested
your changes, and it is seems to work! Let's go with this, even though I'm
a bit skeptical to the limitations incurred.

Also, I've just opened a pull request with python 3 support that I worked
on yesterday.
https://github.com/strongswan/strongswan/pull/10


Cheers,
Björn

2015-03-09 12:42 GMT+01:00 Martin Willi <martin at strongswan.org>:

> Hi Björn,
>
> Thanks for reviewing these changes.
>
> > Nice start on the README. I took a moment to make the python part a bit
> > more "pythonic", and pushed it to a branch on github:
>
> Thanks for the fixes, I've squashed them into the associated commits in
> my branch.
>
> > I've taken a look at your code changes. I definitely agree that
> > implicit error checking is nicer, and it will make the experience of
> > using the library much smoother. There is a problem with your
> > implementation however, you are discarding any errors for commands that
> > require event streaming
>
> Correct, I've tried to address this with [1].
>
> > While generators is a good idea for response streaming, it is not a great
> > fit here. The current implementation works on the assumption that the
> > generator is exhausted before another command starts. There is no way to
> > guarantee this, as the user may draw elements from the generator as
> he/she
> > wishes.
>
> While I agree at some point, IMHO this is how generators in Python work.
> The user should call call close() on it, either implicitly by breaking
> from the iteration loop, or explicitly when manually iterating using
> next().
>
> Ideally, if the user does so we would unsubscribe from the events, and
> prematurely return from the associated command. However, this is
> currently not supported in vici at the daemon side, but we might extend
> that in the future.
> Instead, I'm just stopping calling yield once a GeneratorExit exception
> gets raised. This makes sure the protocol stays in sync, but stops
> returning results to the caller. This is implemented with [2].
>
> > >>> g = s.list_certs()
> > >>> msg = next(g)
> > >>> print s.version()
>
> While this example still fails, the following should work as expected:
>
> >>> g = s.list_certs()
> >>> msg = next(g)
> >>> g.close()
> >>> print s.version()
>
> I think with these changes, the advantages we get with the generator
> approach at least compensate for the disadvantages, given that most
> users iterate using "for" loops.
>
> Best regards
> Martin
>
> [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=be353005
> [2]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=165603b5
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150310/3c2616b2/attachment-0001.html>