This has always been on my todo list, so I'm glad you are looking at it.

The way I would like to achieve this is such that access to say inst.config.set/get() when the server is in the OFFLINE state, is passed automatically to dse.ldif. This way we can have any module that lives under cn=config (ie backends?) work offline too.

So I'm wondering if we can integrate this like that somehow.

As well, I think there is a python ldif module that may be better to use: https://www.python-ldap.org/doc/html/ldif.html . this would give us python entry objects that we can then write to and flush back to dse.ldif.

So in it's current form, I don't think that this is the way we want to go: it adds two paths to editing backends, configs etc. I think we really should make this transparent through the config / backend objects, and have the online/offline state determine if we use dse.ldif vs ldap.

I hope that helps, sorry to be difficult. If I can help with this feature at all, please let me know :)

This has always been on my todo list, so I'm glad you are looking at it.
The way I would like to achieve this is such that access to say inst.config.set/get() when the server is in the OFFLINE state, is passed automatically to dse.ldif. This way we can have any module that lives under cn=config (ie backends?) work offline too.
So I'm wondering if we can integrate this like that somehow.

We can and I think it is a good idea. What comes to my mind, we can still have this module and call it in inst.config/backend.set() when the instance is in the OFFLINE state.
And it will require some testing and additional development... Continue in the last part of the comment.

As well, I think there is a python ldif module that may be better to use: https://www.python-ldap.org/doc/html/ldif.html . this would give us python entry objects that we can then write to and flush back to dse.ldif.

I've looked into it and partially it is depricated (CreateLDIF and ParseLDIF) but that is not the point. Also there is the fork on the github - ldif3 that currently is developed by enthusiasts.
First, I've wanted to use it too, but after some thought, I've decided not to do so because of its API specifics. It will make our code is not so smooth and easily readable. So I've preferred maintainability over some features like (changetype: add/modify/modrdn, working with complex dicts and few entries) that we don't need and I've made it simple as possible and still, it covers our needs for dse.ldif.
Though it is not a problem to add ldif module support (to work with Entry objects), but I don't see the point of building the whole DSEldif class with it because of the reasons above.

So in it's current form, I don't think that this is the way we want to go: it adds two paths to editing backends, configs etc. I think we really should make this transparent through the config / backend objects, and have the online/offline state determine if we use dse.ldif vs ldap.
I hope that helps, sorry to be difficult. If I can help with this feature at all, please let me know :)

Currently, we are in testing phase and we need this module to test new features and probably verify some bugzillas. So the time is of the essence.
I'd say we keep it like this for now (if you're okay with the code) and we will continue to improve the idea later. What do you think?

Sure, let's accept this now, and then we can re-work it later. It's a risk, because a temporary fix has a habit of becoming permanent, but I trust we can work this out properly soon :)

Thank you, William.

To ssh://pagure.io/lib389.git
813f9e8..33bb816 master -> master
commit 33bb816
Author: Simon Pichugin spichugi@redhat.com
Date: Wed May 3 16:03:38 2017 +0200

Ack

To ssh://pagure.io/lib389.git
4e6651a..b46da26 master -> master
commit b46da26
Author: Simon Pichugin spichugi@redhat.com
Date: Mon May 15 09:32:58 2017 +0200

commit f32a14b
Author: Simon Pichugin spichugi@redhat.com
Date: Sun May 28 22:52:57 2017 +0200