freenetwork at web.de schrieb: > Matthew Toseland wrote: > >>> My wishlist for FCP3: >>> >>> * node generated message IDs to ensure true uniqeness and unguessability >>> of node-IDs to protect different FCP client from another >>> >>> >> If the client wants to store an ID. What if it doesn't? More complexity for >> little gain. >> >> > > The client has to store something in any case. If it has an ID, it can > build everything depending on it alone. If it generated the ID by itself > or is given the IDs by an authority (the node) is actually > implementation-wise the same. But if the node gives the IDs the node can > ensure the ID is of valid format (no esoteric characters) and it is > actually easier for the client programmer as he does not have to care > how to create IDs, does not have to check for uniqueness himself, etc. > Just send a message to the node "hey, give me a new ID" and store it. > >>> * usage of JSON [1] for the messages. This is standardized and easily >>> parseable. Another *great* feat is it's easy to convert a JSON-message >>> into a Java bean and vice versa [2], skipping the whole manual parsing >>> of fields altogether and concentrating on the work to do. >>> >>> >> If it's java-specific it's useless, you can always steal the code you need >> from Fred (as jSite does). >> >> > From the site (I suppose you read it before denying it ;) : > "JSON (JavaScript Object Notation) is a lightweight data-interchange > format. It is easy for humans to read and write. It is easy for machines > to parse and generate. [...] JSON is a text format that is completely > language independent but uses conventions that are familiar to > programmers of the C-family of languages, including C, C++, C#, Java, > JavaScript, Perl, Python, and many others. These properties make JSON an > ideal data-interchange language." > > This, actually, makes it ****very**** valuable for our 3rd party > programmers and library developers as they don't have to create a > message parse at all (just the semantic and logic, but this a library > can never provide). > For nearly every language out there does a JSON-library exist that makes > message creation, parsing and handling very easy. > > - Languages that have a JSON-library (from the homepage, there will be > even more!): > ASP, ActionScript, C, C++, C#, ColdFusion, D, Delphi, E, Erland, > Haskell, haXe, Java, JavaScript, Lasso, Lisp, LotusScript, Lua, > Objective C, Objective CAML, OpenLasso, Perl, PHP, Pike, pl/sqp, > PowerShell, Prolog, Python, R, REALBasic, Rebol, Ruby, Squeak, Tcl. > > Every of these has at least one implementation of a JSON-library. To sum > the major languages up: > - C: 5 > - C++: 6 > - C#: 8 > - Delphi: 3 > - Java: 17 > - PHP: 8 > - Python: 6 > >
Fcp should make it easy from some point on to write an Fcp to Json adapter. Then everyone is free to use Json or not. My 2 cents