On 09/09/11 13:52, Stephan Beal wrote:
(...) While there is arguably little use for JSON in CLI mode, i'm trying to keep it all structured so that i can use the same code/commands in both CLI and CGI/server modes (...)
Actually, if the complete CLI functionality was available as JSON output, we'd automatically have our library/frontend model. Think about it, a library is a backend that you communicate with. Typically you call functions in the same address space. The benefit of course is tight integration, compile time safety and what not. The drawback is becoming eminent when you are trying to access it from multiple callers / threads. Do you synchronize, what about locked DBs etc. etc.
Now, if your "library" is actually a server that you communicate with, and the CLI frontend-client is doing the same, anybody who's capable of sending a HTTP request to localhost can use all of fossils capabilities and program on top of it.
What would then be lacking, of course, would be the simple steps that e.g. sync, commit, list, mv, etc. are being composed of. That might be a not-so-herculian effort in the end to make fossil a library.
I haven't given this a looooot of thought, just saying: in the end what we would want from a "fossil library" would be that a) the cli uses the same library so that we are able to be first-class citizens and b) finer grained control and c) a separation of concerns (you, fossil library, take care of the fossil stuff, I take care of invoking hooks, presenting a GUI and slapping my users if they try to do something stupid). a) to c) can be achieved with IPC, too, of course (just look at the COM/CORBA model, remove all the bloat and voila, you have <data-format> over <protocol>).
Btw, I suggest starting a new thread, called: FOSSILS JSON-RPC INTERFACE ;) Just to get "REST" out of people minds...
Regards, -Martin _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
