Forum Discussion
Michel_van_der_
Nimbostratus
NimbostratusWould be nice if...
After a fair bit of playing around with the iControl/SOAP/perl interface, it would seem
that the current API is pretty well organized, but the total package is a tad slow, given
that I have to go back/forth a lot, which in SOAPs case ain't pretty (in my experience).
My code is structured to get some base information and then fill in the details, so it
also switches between e.g. VirtualServer to Pool to VirtualServer to Pool to Rule, etc. My
guess is that the serializing/deserialzing is a big factor here.
:idea: Would there be some value to have some sort of convenience function that can get all
'important' (whatever that is) information in one full swoop, equivalent to looking at the
bigip.conf file, but in a more structured way?
I could off course re-structure my code and
see the result (which I may do after I'm done with my proof of concept), but it would
seem that this is something a lot off people may want to do...
More Random Thoughts as usual.
- Thanks for the input. In fact, we've heard this more than once (internally and externally). Here's a bit of background on the API.
When we first designed the API, it had the following goals
1. Ease of use
2. Extensible
3. Backward compatible
With these in mind, the object by object operation and property accessor model fit most closely. If, for instance, we created a method to retrieve all attributes of a Pool, then if an attribute was removed or a new one was introduced, we would need to create a new method to account for this. This would end up with multiple methods that do the same thing and we believe would cause confusion for the developer.
The same issue applies with a "global" method that returns everything in one big swoop. The signature for this method could never be constant over time. In versions past v4.2 of BIG-IP, we've introduced "bulk" type methods that allow returning lists/statistics/attributes for more than one object in a single request. This would not compromise backward compatibility but could ease the burdon of round-trip times.
Another problem with one "big" method that returns everything relevant is that "everything" is relative to user. To return a entire configuration for a site that has a mammoth configuration (10000 virtual servers - yes we have customers like this), the returned stream would likely cause major problems with client parsers as well as server side memory consumption.
The biggest issue with Perl that I've seen is the SSL negotiation required for each message. As far as I know there is no way to use HTTP keep-alive, but that could solve that problem if it's possible in the SOAP::Lite package.
If you believe you have a solution that addresses our requirements, please let us know as we are very committed to making the life of the iControl user as "pain-free" as possible.
-Joe
