Loading ...
Sorry, an error occurred while loading the content.
 

Re: How to Kill a SVG

Expand Messages
  • Gordon Bowman
    ... global ... original ... renamed and ... True, but even with the DOM methods unchanged, we ve all written algorithms that have indepth comments to help us
    Message 1 of 7 , May 2 6:08 PM
      --- In svg-developers@yahoogroups.com, "Jim Ley" <jim@j...> wrote:
      >
      > "Gordon Bowman" <gordon_bowman@h...> wrote in message
      > news:c71q4e+keu1@e...
      > > Any obfuscated code can be unobfuscated, but it's only trivial if
      > > the obfuscation process itself was trivial, e.g. garbled via
      global
      > > search and replace. Even then, you're guessing at what the
      original
      > > variable names are, losing the semantics of it, and making it
      > > difficult for the code to be maintable without a lot of work in
      > > figuring out what variables and functions are actually for and
      > > naming them appropriately.
      >
      > Not particularly difficult since the DOM interactions cannot be
      renamed and
      > they're the key elements for understanding what the code does.

      True, but even with the DOM methods unchanged, we've all written
      algorithms that have indepth comments to help us understand the
      logic behind it at a later date. When those comments and the
      meaningful variable names disappear, it can take time to make sense
      of it all, intact DOM methods or no.
      >
      > > Obfuscation can get a lot more
      > > complicated, of course, with flow-control obfuscation,
      encryption,
      > > etc. Basically, obfuscation simply serves as a deterrent, making
      it
      > > more trouble than it's worth to try to steal the code instead of
      > > legally writing it from scratch.
      >
      > I would say obfuscations only value is in rebutting a defence of
      accidental
      > mis-use of your code when someone has stolen it, if there were
      steps needed
      > to read the code.

      Yes, I forgot that one. But I would say this is "another" value of
      obscuation, not the only one.
      >
      > The "more trouble to steal than rewrite" I find on the web is
      generally
      > achieved just by not writing very good script.
      >
      > > As well, as I mentioned in a post last summer, obfuscation can
      also
      > > improve the run-time performance (as well as making the code size
      > > smaller). Back when I was working on Corel's dSVG, we found that
      the
      > > obfuscated code outperformed the non-obfuscated
      > > code "significantly".
      >
      > Yep, I've seen that a stated a lot, it's also undoubtedly true if
      you don't
      > optimise your code as you write it, but I've never seen it true
      against code
      > which has been written for speed. (The general reason is the
      caching of
      > references which you get as part of the obfuscation process, you
      can just do
      > that yourself.)

      The obfuscation that resulted in improved performance was a simple
      search and replace, nothing intelligent about it.

      > So whilst you could gain this optimisation you do it at a
      conisderable
      > support and QA cost - you're QA'ing different code to what you
      develop
      > against, line numbers and variable names mentioned in errors are
      different
      > to what you develop against.

      That's not really any different than the standard practice of
      developing a C++ application in DEBUG mode, while giving optimized
      RELEASE builds to QA.
    Your message has been successfully submitted and would be delivered to recipients shortly.