At 10:59 -0700 2001_08_15, Watson, Christopher wrote:
Hi Watson, these are my answers of the top my hat:
First of all, I think you might be able to use a LDM (Linked Dir Movie).
It will link to an open .dir file in authoring, while providing
protection of your code.
It will have to be placed in the score, at least while you
instantiate, or "extract" the classes.
You could instantiate a containerClass, from the LDM into a
persistent variable in the stageScope, through the "tell sprite"
syntax.
Then "forget" the LDM, and access your scripts from the containerObject.
You can instantiate a script directly from a variable, even if the
source-script-member is no longer available.
>1) Is this enough protection? Meaning, is the readable Lingo in a .cxt or
>.cct completely, and forever, inaccessible?
I believe the shocked lib is most thorough in stripping out any sourcecode.
>2) Is the .cxt or .cct file usable as a linkable external cast just as
>easily and reliably as an unprotected .cst file? Are there any technical
>"gotchas" here?
No you can't easily link to a protected lib in the Authoring
environment, and you would risk blowing the scripts away at recompile
anyway. You *can* open a protected lib in authoring, if you first
link to it from a Miaw. This sort of fools Directors security
mechanism.
>3) How about in authoring mode?
Crap I guess.
>4) Could someone please characterize for me the opinions of the
>"middle-user" community regarding protected casts? Are they generally
>well-received, or frowned upon?
Given the complexity of the DOM XML context, I'd think your
"middle-user", should at least have external libs in the pocket.
>5) Could someone please characterize for me how a protected external cast
>rates against an Xtra with identical functionality? When used within the
>environs of Shockwave, isn't an externally linked cast easier to deal with
>for the end user than an Xtra which must be downloaded through a secure
>certificate? Or is that a false perception?
As far as you can transparently "install" the castlib without
intimidating the enduser, it has this advantage over Xtras that
require obtrusive alerts.
On a performance level, I'd guess that a pure lingo solution looses
hard against a real Xtra.
This is mostly string operations and they're notoriously slow in
Lingo, but you must have feel for that by now.
You might get significant performance gains on large datasets, by
using the textCruncher Xtra, but that defeats...
>6) If the "product" (as an external cast) is just as much a demonstration of
>the capabilities of Lingo to implement an open standard as it is to provide
>functionality for the end-user, are there still strong arguments for
>implementing the functionality as an Xtra?
That would be performance.
But it's an odd question, because then you wouldn't be demonstrating
Lingo, would you?
Jakob
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
