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

RE: RE�: [json] __jsonclass__ hint ing

Expand Messages
  • Atif Aziz
    ... 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
    Message 1 of 2 , Jul 31, 2006
    • 0 Attachment
      >>
      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
      <<

      I'll admit that the roots are in RPC, but the application of the solution is quite general when you consider that RPC is nothing more than structured request and response.

      > Your assumption here is that the end-point
      > returns only one type of regularized data.

      In the 90% case, yes. For the 10% case where the data ends up being dynamic in shape from invocation to invocation, I'm hoping that the frameworks will step in and provide a way to designate a field as the type discriminator. The upside of this is that you get tremendous flexibility and no one needs to define a standard. The producer shapes the data and the consumer maps it to their manner of convenience. The downside is that you'll need fairly mature frameworks to deal with this sort of mapping.

      >>
      object GetPageData();
      This is where runtime __jstype comes in.
      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.
      <<

      Obviously, if the client and server know the types and have been able to describe it to each other in a neutral manner, then you're already ahead of me. :)

      >>
      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.
      <<

      True and in this case, the only purpose the schema will be serving is in describing the shape of JSON objects. That is, what properties they are expected to carry and of which of the basic types. Again, this is only beneficial for the strongly-typed languages camp.

      BTW, I've come to the conclusion that there are only 5 types interesting for schemas: Boolean, Number, String, Array and Object. It is useless to recognize Null as a type since it can only bear one run-time value.

      ________________________________________
      From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of meyer_jon
      Sent: Tuesday, July 25, 2006 5:11 PM
      To: json@yahoogroups.com
      Subject: Re: RE�: [json] __jsonclass__ hinting

      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.
    • meyer_jon
      ... I guess this is our point of departure. You view dynamic data as a 10% rare case that falls outside what you are interested in, one which you hope others
      Message 2 of 2 , Aug 1 5:30 PM
      • 0 Attachment
        > In the 90% case, yes. For the 10% case where the data ends up
        > being dynamic in shape from invocation to invocation, I'm
        > hoping that the frameworks will step in and provide a
        > way to designate a field as the type discriminator.

        I guess this is our point of departure.

        You view dynamic data as a 10% rare case that falls outside what you
        are interested in, one which you hope others will figure out.

        I have a dynamic app - one where the user can turn on and off
        different options, and as they do a single RPC method returns
        different types of JSON objects. Is that really so rare? I don't think so.

        Are others out there doing dynamic data interchanges in JSON like this?

        Type hinting is hardly controversial. As evidence, consider that every
        mature JSON serializer has a way of doing it. JSON-RPC-Java uses
        javaClass:

        {
        "javaClass": "java.util.ArrayList",
        "list": [0, 1, 2, 3, 4]
        }

        Refeed uses "jsonclass":

        {"jsonclass": ["RF_Feed", [{"id": 3}]]}.

        json-rpc.org uses "__jsonclass__":

        {"__jsonclass__": ["MyDate", [2005, 4, 4]]}

        We use "jstype":

        {"jstype": "MyDate"}

        And that's just the problem: right now everyone has a different
        attribute name and slightly different technique for doing exactly the
        same thing - tagging a { } struct with a type name. Surely this this
        is the kind of thing a standard should address?

        Relegating dynamic data to the "10%" case is shortsighted. Sure,
        static data is common. But so is dyanamic data. Addressing dynamic
        data enables a range of richer apps. As JSON matures these richer apps
        are going to dominate.

        Its a bit like a C programmer arguing that, since 90% of data is
        static, and typedef covers that, who needs class? That position stuck
        for many years, and as a result every single C coder had to create a
        homegrown solution for doing classes in C - it was a mess.

        Fortunately, JavaScript is already object oriented. And so are nearly
        all server languages. Expecting data to be static 90% of the time is
        ignoring the nature of the web.
      Your message has been successfully submitted and would be delivered to recipients shortly.