Re: [caplet] Re: The Module Tag
- David Hopwood wrote:
> Douglas Crockford wrote:I see that even that page says:
>> --- In email@example.com, David Hopwood <david.hopwood@...> wrote:
>>> Douglas Crockford wrote, in May:
>>>> How does this fit in a capability network?
>>> # Communication is restricted only to JSON text. JSON text allows
>>> # exchange of simple or complex data structures without the capability
>>> Restricting to JSON is a good idea only if there exists a standardized
>>> to do that using 'eval'.
>> The parseJSON method is available at http://www.json.org/js.html
# To convert a JSON text into an object, use the eval() function.
before pointing out why you shouldn't do that. It should be changed
to be less self-contradictory.
>> It will be standard equipment in the next edition of ECMAScript.The .toJSONString() methods specified and implemented at
<http://www.json.org/json.js> will not terminate successfully when
passed a cyclic structure. I don't think it is OK to place a requirement
on the caller to pass an acyclic structure, without specifying what
happens if it is cyclic.
If for some reason it isn't considered desirable to pass cyclic
structures between compartments (vats, iframes, etc.), then this
should be specified to cause an exception, rather than a stack
overflow exception being a side-effect of a particular implementation.
Another problem with those methods is:
// Values without a JSON representation are ignored.
This is broken; values without a JSON representation should cause an
> That's good. I still think that exchanging deep-copied objects directly... and would correctly handle cycles.
> would be more convenient.
> It also allows immutable objects to be sharedActually this is not straightforward to implement because of the ability
> between sender and recipient, rather than being copied unnecessarily (as
> well as saving the memory for the [Unicode] JSON string).
compartment is to be allowed to change the prototypes for object, String,
etc., then objects can't safely be shared between compartments [*].
I consider this a language design flaw, BTW.
[*] At least, not without some deep magic, such as treating an object as
having different prototypes depending on what compartment it is being
used from. Actually, forget I mentioned that; I disclaim all
responsibility for that idea ;-)
> Note that if the deep copy is defined to be equivalent to converting to--
> JSON and back using the JSON bindings of the sending and receiving
> languages, there is no cross-language interoperability problem with this.
David Hopwood <david.hopwood@...>
- --- In firstname.lastname@example.org, David Hopwood <david.hopwood@...> wrote:
> Actually this is not straightforward to implement because of the abilityString,
> compartment is to be allowed to change the prototypes for object,
> I consider this a language design flaw, BTW.
Welcome to my world.
- On 7/12/07, David Hopwood <david.hopwood@...> wrote:
> // Values without a JSON representation are ignored.Actually, I'd prefer to pass in a function that is given the
> This is broken; values without a JSON representation should cause an
opportunity to convert the value to one that does have a JSON
representation. For example, this feature could be used to export a
web-key (capability URL) for the non-JSON values.
The web-calculus is the union of REST and capability-based security:
Name your trusted sites to distinguish them from phishing sites.