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

Re: RE�: [json] __jsonclass__ hinting

Expand Messages
  • meyer_jon
    ... I don t yet see how you define time or person . How do you support enums? What about multidimensional arrays? Subclassing? My impression is that in
    Message 1 of 5 , Jul 25, 2006
    • 0 Attachment
      I guess I need to wait for the full document - in your example:

      > { "name" : "string",
      > "sirname" : "string",
      > "birthday" : "string/time"
      > "children" : {
      > type : "array/object/person",
      > maxLength : 10,
      > nullable : false
      > }

      I don't yet see how you define "time" or "person". How do you support
      enums? What about multidimensional arrays? Subclassing?

      My impression is that in formulating the spec you are mostly thinking
      about RPC being used to sending normalized data tables e.g. from a
      database - a scenario which fits well with using an external schema
      definition. The Yahoo service you mention is one such example. As you
      say, you want to:

      > providing a machine-readable
      > way of describing the expected structure of some JSON data
      > in advance to (rather than during) the reception of the data.

      You also point out that

      > Given just this piece of JSON data, you can't say anything
      > about it *unless* you consider *where* it came from. If the source
      > end-point has a way to describe its structure and the structure
      > of its results then you've got what you wanted.

      Your assumption here is that the end-point returns only one type of
      regularized data. But our app has RCP endpoints like:

      object GetPageData();

      where, according to how the user has configured their page, different
      objects are returned. Think of netvibes (www.netvibes.com). Presumably
      they have a call like:

      object[] GetColumnContents()

      which returns different types of objects according to what modules the
      user has dragged onto a page.

      In this scenario, RPC is being used not to send database tables but
      rather dynamic graphs of objects. For us, knowing "where it came from"
      and "in advance" cannot tell us the structure of the data.

      This seems like a very reasonable use of JSON-RCP, but it requires
      support for sending dynamically typed data, where you can do:

      var x = server.GetPageData();
      if (x instanceof Person) { ... }

      This is where runtime __jstype comes in.

      You could argue that this is a niche use of RPC. But my impression is
      that, as Ajax matures, you will see much more of this kind of thing -
      and the standards process is slow so its important to be forward looking.

      Regarding:

      > How does it help to know that
      > "__jstype" is a person when I don't have a standard way to describe what
      > person data could look like?
      >

      In our case we've already defined a Person class on both the client
      and the server. So our app already knows what a Person looks like. We
      just want to be able to pass Person instances back and forth using RPC.

      >
      > > I don't see how adding type hints changes security issues.
      > If it is checking against the wrong schema based on the
      > type hint then there's trouble looming, no?

      Secure servers are written defensively. They never assume that
      the messaging layer produces valid messages. Any data from a client
      is checked against an internal schema maintained on the server.
      Changing __jstypes in a message might confuse the Serializer, but it
      shouldn't get past the internal security checks.

      > > You make a claim that "parties that don't understand the extension can
      > > still work with the basic types they know about." I see this as a
      > > false claim.
      >
      > Care to expand? Can't let you get away with just that. ;)

      My point is if you only care about the 6 basic types, you don't
      need a type schema at all, because JSON is already happily
      unambiguous when it comes to those 6 basic types. If you receive a
      message, there's no way you can mistake a string for a bool for a
      number. That's one of the great things about JSON.
    • Shawn Silverman
      ... Just some thoughts.. I was experimenting with different ways to name things and came up with these: 1) Name the anonymous members using some sort of
      Message 2 of 5 , Jul 27, 2006
      • 0 Attachment
        > new element names. All the objects in JSON are anonymous, you just have:
        >
        > {
        > "firstName":"Joe",
        > "age":22,
        > }
        >
        > As soon as you have any non-trivial data structure (even just a
        > Hashtable of objects), you need a __jstype mechanism. This need is
        > much greater in JSON than xsi:type is in Xml.
        >
        > I don't agree with your arguments for why a type hint would never take
        > off: Everyone working with JSON in typed languages is adding some kind
        > of type hinting, the need for this is very apparent.

        Just some thoughts.. I was experimenting with different ways to name things and came up
        with these:

        1) Name the anonymous members using some sort of extended syntax.

        <Person>{
        "name": "Fred",
        "age":22
        }

        2) Alternatively, allow one of these inside an object:

        {
        <Person>,
        "name": "Fred"
        }

        3) JSON already has a way to do this (sort of):

        {
        "Person":{ "name":"Fred", "age":22 }
        }

        4) This could be extended:

        {
        "Person":{ "name":"Fred", "age":22 }
        "isInstance":true
        }

        Or we could have "isClass", etc.

        5) This could be used to define types instead:

        <Person>{
        "property":"name",
        "property":"age"
        }

        6) This could be shrunk:

        <Person>["name", "age"]

        7) Or:

        <Person>[{"name":"string"},{"age":number}]

        etc...

        I think of JSON more as the "lexing" layer with a few extra types, and then the meaning is
        tacked on by some sort of external program or schema.

        Just some random thoughts on the subject...

        -Shawn
      Your message has been successfully submitted and would be delivered to recipients shortly.