Re: Fcp woes ..final

On Friday 21 March 2008 09:43, freenetwork-S0/[email protected] wrote:
> 
> 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.

With the current protocol there is no reason to exclude any character except 
newline.

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

If they want to use DDA they will have to provide a nontrivial library.

> 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
> 
> >> If requested, I can provide elaborate snippets how to use the beanifying.
> >>
> >>
> >> [1]
> >> http://en.wikipedia.org/wiki/JSON
> >> http://json.org/ (notice all the JSON-libraries freely available)
> >>
> >> [2]
> >> http://json-lib.sourceforge.net/index.html (there are more)

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBH475/A9rUluQ9pFARAqAcAJ9iZrWpgl21HzYP1mhGPOpdyIqo9wCgkPQF
hzjA8OqBNmOYI7mTZnMPViQ=
=tK+V
-----END PGP SIGNATURE-----