I agree that if your are going to integrate some language with fossil then Jim Tcl is nearly an ideal fit. It is small, modular, self contained, can replace TH1 easily and should be licence compatible.
But... let's see a design proposal, or at least a prototype implementation. I think that understanding some core use cases and designing a good API is important. Regarding someone's concern over Tcl vs Jim Tcl differences - yes there are differences, but in practice they are unlikely to be a problem. Take a look at the online doc http://repo.or.cz/w/jimtcl.git/blob_plain/HEAD:/Tcl_shipped.html Cheers, Steve On 21/09/2011, at 6:05 AM, "Martin S. Weber" <martin.we...@nist.gov> wrote: > Why don't we all save the napalm for when we've come up with a real design > proposal for > > a) making fossil a library, and > b) integrating $LANG with a) > > The whole argument is somewhat bogus until then, although the voice of > concerns is valuable input for creating said design proposal. I don't see why > we should delve into details of a potential integration without having > thought out these details. I plead guilty of getting carried away with > reacting to some of these concerns; after all all I wanted to do was answer > Stephan's question positively. > > Regards, > > -Martin > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
