3 ms·
Wow - thanks so much for going through all the links and getting an example working - on a phone no less!! :) very impressive! Hmm, machineless, now that is int
by mands 11y ago
Wow - thanks so much for going through all the links and getting an example working - on a phone no less!! :) very impressive! Hmm, machineless, now that is interesting - I imagine with phone processors such a thing will become, if not already is, possible.
Yes! I wish there was a way to really define and lock-down exactly what communication/serialisation primitives are required to aid communication between systems. Though I imagine you are right in that we've come quite far with common practices.
Haha - yes the Barrister docs can be a bit confusing - we are getting around to writing a simpler version of them with common examples and use-cases. We really like the schema itself as it does map onto JSON semantics quite nicely.
1) Yep, the messaging format could def be simpler! We just felt that as we're starting out it would be better to stick with standards, even if, as you say, they are nascent. This reduces the amount of things we have to do but also we hope that people much smarter than have thought about the issues involved! Hopefully the client-side bindings will hide most but if needed it's nice to now you can drop down to the JSON format.
2) Hmm, JSON by example, this is super interesting!! I fully understand where you are coming from and it seems so much simpler than JSON-Schema (I was never a fan) Using values as types is quite elegant, and reminds me of some of the type-level programming stuff in the functional circles.
The use of multiple entries in a JSON object seems like a nice way to express sum types - something we are really keen to add to the Barrister IDL (you can extend from an object but I believe there is only a single tree). As you note, although this valid JSON, it may require a custom parser to extract. I'd love to hear more about this technique tho, has it been used elsewhere or is there any further documentation?
3) Primitives - yes, it'd certainly be possible to specify other primitives by encoding them in the JSON string value. Could be risky, as you suggest, when you start looking at regexes and so on - I've not been the biggest fan of defining these as types in the past. Also, how would one go about defining a user-defined type at the equivalent level of a primitive? Super interesting tho, if you have any more thoughts on this I'd love to read them.
- hyperpallium 11y agoRereading, my comment was utterly misleading about "machineless"! I meant no local development. All in the cloud + browser (or another client). So a phone just needs a browser. [see my other reply] I missed the Barrister IDL-JSON binding... kinda important! I must check how they bind choice/sum/polymorphism to JSON... 2) JSON by example schema: Thanks! It's never been used; the above comment is the only documentation. Maybe I should write a RFC... or at least first draft of a spec. And a reference implementation. Actually using this schema to validate JSON instances requires using all the fields to determine which branch you have. They can have fields with the same name, provided the entire set is distinct. So these are OK (letters as fieldnames): {a,x}+{a,y}; {a,b}+{a}; {a}+{} (empty object) Thinking further, duplicate fields implies a different data model, and most JSON parsers will use a hash. Maybe it would ease adoption to fake up a syntax (eg addr-1, addr-2, addr-3 for the "same" field, with escaping rules for '-'). I wonder wonder about usage: maybe apps don't use this approach (same field can have different kinds/types of values); maybe they use a field for each type, only having a value for one of them? (or an explicit "type" field). It's important to model common practice. But I think JS coders do use polymorphic behaviour (same method names with different code). 3) Add more primitve types. Thinking further, although people end up wanting more precise primitive types for storing data, if JSON is mainly used for transferring values between languages, it really need only be as expressive as the languages themselves, which generally don't go into details like syntactic nature of primitive values and ranges of integers and lists etc. (They wrap these concepts in objects; JSON can too). I'm stepping back from the idea - I just liked that you could add richer types without losing the property of looking like JSON - but you do lose the property of representing types with the types of JSON values. Can leave the extra sophistication to xml schema (and json schema) for those who need it. Unless JSON itself add more primitive types (which I doubt!). PS: one more comment to go. I plan to reread your previous comments on CORBA etc now I have a better idea where you're coming from.