Note, that the current behavior of
ad_conn request seems nowhere documented. I do not believe that there are applications aside ds that rely on it. The documentation says:
Valid options for ad_conn are: request, sec_validated, browser_id, session_id, user_id, token, last_issue, deferred_dml, start_clicks, node_id, object_id, object_url, object_type, package_id, package_url, instance_name, package_key, extra_url, system_p, path_info, recursion_count.
Therefore i would not regard this a change of the public interface, but rather a bugfix or an internal change. A switch for backward-comaptibiliy seems a overkill and impractical, since any code relying on the proposed behavior would need the same switch. The current behavior is
ad_conn request
30
ns_conn request
POST /ds/shell HTTP/1.1
See, this is something completely different. I have no personal interest in changing this, but was simply trapped by this behavior when experimenting with the xotcl-based ad_conn. The proposed change is completely independent from xotcl. Implementing this change with fixing all affected places in the packages of oacs-5-2 costs most probably less time than writing this summary.
Actually, the new xotcl-based ad_conn is more complicated than it needs to be, since it tries to be fully backward compatible with the current one. So, according to the TIP rules, this would not require a TIP.
The new version is more complicated than needed, since it has to deal with e.g. accessing and modifying the global (undocumented) associative array ad_conn()), it should stop forwarding to ns_conn, once the values were overwritten via -set, and it has to be compatible with the approach of the current ad_conn to check whether the command/object was initialzed already (the current ad_conn command is always available and has to be initialized with -reset). Furthermore the method calls to ad_conn have the form of a flag (starting with a -) while reading the values happens through methods. As a consequence, i would not regard the implementation of ad_conn in xotcl as cleanest the most beautiful way expressing the required semantics. One would have done this probably different haveing a more general object framework in mind, without inventing per-command different semantics.
Conceptually, ad_conn is more a connection or a request object than a connection command. As an object, it should be created early in the request processor and deleted when the request is over (in xotcl terminology a volatile object). This would care for initialization, cleanup etc. I would not regard the overwriting of values from ns_conn as a good practice (but we do this as well in learn@wu for getting the peer address from before pound). As object, the initialization is straightworward. ad_conn could be seen as an instance of a subclass from ns_conn and should provide means for further subclassing. All calls should go through the same interface.
So, what i am saying here is that in order to make ad_conn a nice and well designed piece of code, much more is needed to be done than simply reimplementing it in a faster manner. Such a re-design would certainly make some discussions and a tip necessary. But i doubt it makes sense in 5.3 to require a tip for every use of xotcl in core functions ...
