Remigiusz Modrzejewski <l...@maxnet.org.pl> wrote: >>> Actually... No. Fossil, with it's monolithic single-app design, is >>> relatively hard to both extend and embed. >> >> Actually there are two kinds of people in the world, those who expect >> something to do whatever they think it should, and those who look at >> what it is designed to do, and how it is designed to be used, and >then >> either use it accordingly or find something else. >> >> Of course success in extending or embedding depends on the level of >> available skill in awk or Perl or Expect or whatever. Remember that >the >> target end-user for Fossil is a developer! > >Yeah, you pretty nailed it. A perfect explanation why Fossil's >integrations into various IDE's, GUI front-ends and other integrations >are so popular. I may be OK with CLI, but it already bit me a few >times: I can not use Fossil in my day job, because there's no Eclipse >plugin (apart from that, the team said "whatever", we're free to start >new projects in whatever VCS that Eclipse supports).
Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. The mercurial folks have a Python API, but strongly recommend that you just run hg, as they work to keep that compatible between versions, and make no such effort with the Python API. It seems to have a plugin for most GUI IDEs. >>> But don't say it's easy to extend by writing a separate client or >ipc-ing >>> to this one... >> >> Why not, it's a perfectly acceptable technique. > >Acceptable, yes, in some circumstances. In *far* more circumstances than linking to a library is acceptable. >But compare: open3 a process and parse the output (is it even >guaranteed to be stable?) to a function call... Well, an API - no matter how it's implemented - is only as stable as the developers make it. Whether or not you break an API when you upgrade the provider depends *far* more on the developers than whether they chose to provide it via an executable or a shared library. And if you're going to compare them, compare the entire process: One is - well, open the executable and parse the output. The other is: select a language that can be coerced into linking with the library you want to use, write or find a wrapper if it's required that will translate between calling conventions and data types, load the shared library and wrapper code, and *now* you can call your wrapper to get and convert the data. Oh, and if you want to let someone else use your plugin, you have to make sure all the licenses involved are compatible. Nuts, after writing the Python wrapper for the perforce C++ library, I wound up rewriting it for our Windows group to use the p4 command instead of the library, because that was easier & cheaper than buying the C++ compiler used to build the Perforce Windows binary and porting Python to it. But it made our support scripts portable across Windows and Unix. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
