Conga Questions

[paulmansour]

It appears the X509Cert class requires a reference to an instance of the LIB class, even if not calling any deprecated shared methods (like ReadCertFromFile) that can be called directly from LIB.

I think in one spot here:

Code: Select all

:If 0=1⊃z←LDRC.Certs'Decode'_Cert('Details'i),_usemsstoreapi/⊂'DecodeApi' 'store'

It is not clear to me what exactly LDRC.Certs is. Certs appears to be neither a property nor method of the LIB class.

What is a bit disconcerting is that LDRC (which is an instance of the LIB class) is a shared property of X509Cert. So if I have multiple instances of LIB and and X509Cert, all the instances of X509Cert will point to the same instance of LIB. Maybe it matters not, I don't know, as I have no idea what LDRC.Certs is, but it would appear that it dependent on the instance.

Also, all of the ReadCertFrom*** methods in LIB are instance methods. Should they be static? Do they have anything to do with the instance of LIB?

[paulmansour]

OK, it looks like LIB.Certs is a public method (shared I think, if that is the default) - not sure why I didn't see that before. So it probably matters not what instance of LIB is in X509Cert. If that is the case, is there any reason X509Cert does not just have a built-in refence to LIB?

(EDIT: Looks like instance is the default, so if this is an instance method, then maybe it matters what the instance of LIB is, though a quick glance at the code indicates not.

[Morten|Dyalog]

Hi Paul! I believe your analysis is correct: it should not matter what the instance of LIB is. The Certs method is a cover for a stateless function in the DLL used to decode certificates and any instance will do. We can certainly see room for improvement in that code and will review it as we work on the next release of Conga (for example, there is a potential problem releasing that shared ref if you need to shut things down).

The root problem is caused by wanting to use multiple independent components written in APL that all want to do communications without interfering with each other. In this age where pretty much every APL application component - including development tools - wants to use Conga, I am wondering whether we should do something radical. I am considering simply having the interpreter load the Conga DLL at startup, so the Conga API is permanently available, without APL code having to deal with the complexity of determining when (and how) to load or unload Conga itself. The availability of multiple object roots should then be enough for applications to have their own "Virtual Conga Machine".

In the early days where Conga was infrequently used and there were significant feature upgrades in new versions of Conga, it made sense for components to use different versions of Conga and therefore need to manage this carefully, but I think it has now settled down so much that it would be OK to dictate that all applications use the same version.

[paulmansour]

Thanks Morten.

Regardless of whether or not Conga is integrated right into the interpreter, it would seem some general restructuring, refactoring and renaming would be a good idea. There are instances of "Conga root object", "LIB", "DRC", "functions", not methods, it's all very confusing.

I understand there is a lot of history, but at some point I think it would be a benefit if the documentation was rewritten to reflect they way things are now (or should be now), and all the version, history, and nuances of the old stuff be relegated to an appendix. For the new user (and me) it is really painful.

As a general rule, I think it better that documentation reads (in the main part) as if there was no past (even though the past is important), and for those interested in the past, look in an appendix. Slogging through the history and versions and compatibility, and names of things that are now defunct, is painful.

[Morten|Dyalog]

As a general rule, I think it is better that documentation reads (in the main part) as if there was no past (even though the past is important), and for those interested in the past, look in an appendix.

Agreed. Conga has transitioned from being a bleeding edge tool used by a few people to something that is used in just about every application that is written, and we have not properly adjusted to this yet. There are plans afoot to grow our technical writing capability next year, hopefully we'll be able to revise a lot of documentation as a result of that.

Another interesting challenge is to satisfy customers who not only want to read the documentation but also the code, which contains potentially confusing warts and strategies which are in transition ;-). I'm not sure we can promise to eliminate all of those.

I hope you have some enjoyable time off with family and friends coming up next week, and look forward to your continued input in the years to come!