I found OCUG sessions as a great source of information and a rare opportunity to learn a lot about the industry and how customers use our products. However, in one or two particular sessions, I felt some details about our products deserves more positive treatment.
For example, in one session on RDC application, a significant emphasis was placed on appending the RDC app URL with some additional URL parameters to put that user session into debug mode. Listening to the particular way the subject was handled, I felt the same information could have presented in a better light.
So, let me explain..these URL parameters are no accident and not a common weakness one could exploit. They are there because development intentionally put them there and backs them with code behind them. These are mostly to help provide additional information to the support and dev personnel when customers run into issues at sites. These parameters are no big secret and we welcome everyone to know about them. The only reason, if at all, for any of these to be not widely publicized is that - often it is not enough to know about the existence of these parameters but most importantly one need to know about how to interpret the information (often notoriously cryptic) collected from turning them on. For example, in RDC 4.5.3, we have introduced a new parameter to profile the client code. And for the most part, information collected via this parameter makes sense only if one is intimately familiar with the code, otherwise it is kind of gibberish.
Also, collecting debug information by logging to a file or disk impacts application performance. So, we have provided two seperate ways to turn on debugging logs. First, just for a user session by way of URL parameters and second for all users connected to the application by way of server side configuration setting parameter. See, that's a good thing, right? I wish that's how it was presented.
Having said that, I wish options such as specifying a database name to log into and switching between production/testmode are not made into URL options as we currently do. I wish they rather follow the standards and be presented as explicit options in the UI on the login screen. I want to see them disappear from the url some day.
Other outrageous example I have seen in the same session is - a weak attempt at some how associating a universally known fact about decompiling java class files with the topic of debugging RDC application.
First of all, every java developer on the planet worth any, knows about how to decompile java class files and at the same time a very small fraction of them may have ever done it for a truely useful purpose let alone for debugging a third party product that they are not working on. As a customer, if you have to get to the level of decompiling the source files, figure out our code, and tell us back about what is wrong in the code, then probably we all don't deserve to be get paid from Oracle :-). My sincere and useful advice to you is - don't ever think about decompiling java classes to resolve not just our product problems but for any other products from any other vendors. Instead, file a bug and demand a fix from support.
I will write in detail about all the URL parameters supported in 4.5.3 later..
No comments:
Post a Comment