Brad, Regarding WDDX I have some (admittedly hazy) recollection as to its origin and development that I gained from using it to port stock quotes from CF to Java, ASP, Perl and PHP. Here's what I remember - but take it with a grain of salt since I'm pulling this out of my a...er....ear.
WDDX is a pretty old standard going all the way back to CF 4. It was originally developed by the Allaire guy (an fellow who's name escapes me - I had great difficulty pronouncing it anyway:) who was responsible for most of the CF original engine. He used it in an ingenious fashion to marshal data back and forth between various internal modules of CF and decided it should be exposed externally so he implemented CFWDDX. Since it's original intent was superseded by advances in serialization I suspect that it is not longer used like that internal. It has not changed a great deal from those days. Certainly the standard is the same since the late 90s. It is a very useful and light weight way to retain objects in a flat format (exactly as you are using it) but I would not expect it to get much attention from the current development effort of CF. I suspect it's left in there as a legacy and I'm guessing that it frustrates some of the Java gurus tasked with porting the CF code from the old C++ days... It's just a guess :) Maybe Ben Forta or one of the other gurus who sometimes monitor this list can shed some lite on it or correct my foggy recollection. I like what you are doing with WDDX and I get the idea - I just think that WDDX itself might be a weak link in the chain. Having said that - the case you mentioned where an SP is throwing multiple nested errors certainly must be an exception. In most cases I think it would work quite well. -Mark -----Original Message----- From: Brad Wood [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 2:20 PM To: CF-Talk Subject: RE: dumpy goodness > My guess would be that the SQL code behind the error is quite large That much did turn out to be true. > pushes WDDX beyond it's buffer limit. In the old days you couldn't build a > packet bigger than 64k (or something like that). That sort of makes sense (but not really-- I would have expected more from CF than that). That wouldn't explain why dumping it gave me a 500 NULL unless it was SUUPER huge. I've dumped some meaty result sets before without trouble. I guess the different was how far it was nested-- several hundred levels deep. The individual structs weren't too big probably-- just deep. > Out of curiosity - what is the purpose of serializing the cfcatch object? Like I said-- for error logging. We have a pretty cool system of CFC's for logging errors as well as other processes in our system. We log Java errors (from our Java team's apps), CF errors, and JS errors (via JavaScript try catches that call an error logging web service). We capture who did it, when they did it, what server they were on, what version of browser they were using, the full cfcatch object (or JavaScript error object), the form and url scope and a couple of other things. A scheduled job E-mails out all of our application's errors every 15 minutes to a group of people to monitor them and put in bug fixes if necessary. That way we can report on who is getting errors, what they are, and when. Since cfcatch is a complex object, it needs to be serialized for storage in the database. ~Brad ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finder&productID=1522&loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:293169 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
