Hi Alex, this is a complex issue, and we won't have easy solution.
First point, we have to stress the fact that this is not a 'stable' version, or as we discussed it a few months ago, this is an intermediate version. So implementing a partial solution is not really a problem. This being said, here are some thoughts, comments inline : > I don't think we should add this feature without having the ability to mark > schemas, and individual schema > elements as read-only (exposed in subschemaSubentry as X-READ-ONLY schema > extension). Only the > administrator and owner of the schema should have the ability to revert the > read only flag. Even the admin > should not be able to delete schema elements with or without the cascade > control present if any element > in the dependency chain is marked read only. The main problem is that we have no idea about the potential impact of a schema modification before we see its real impact on an existing base. Now, we also must assume that the admin 'knows' what he is doing (this is a wish ;). I have read a discussion about the removal of the m-oid attribute and its consequences. I felt like it was pretty much a discussion about what will happen to someone who play russian roulet with 6 bullets in the gun... Brain damages will be at least severe, but there is no way to fix the gun to avoid such damages ! Ok, I agree that the meta-schema should _not_ be writable. And I also agree that the core schemas should _not_ be writable either. So let's use this feature quickly. > Now here is my dilema. I would never allow a production grade release > without having these checks in > place. Just imagine what would happen if the admin deleted the 'top' > objectClass or the 'name' > attributeType: a large amount of the schema would be blown away and the > server would be rendered > useless although blowing away the schema partition folder will recreate it > with the defaults. The admin who delete the 'top' objectClass should be punished for his sins ! Ok, seriously, there are some objects which need to be protected. We may add a dsaOperation attribute in such objects to protect them against destruction. And we can also create a control if we _really_ need to destroy those objects for some reason (a combinaison of a delete operation and this specific control will allow the desctruction). wdyt ? > > Another option is to disable cascade deletes for now and just support > cascading modifications? I would suggest that we allow deletes and modifications first, and restrict them later. It would be so good if we have a way to keep an history for the schema (a kind of svn repo inside the server), and allow the admin to revert his changes back to a stable version ! I guess this could be possible, but I don't know how much it could cost to implement such a feature ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
