I would just like to add that fossil already has a defined API in the
sense that what a fossil repo and server are is described in
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and
http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say that
any truly useful fossil
On Wed, Jul 24, 2013 at 10:43 AM, Mark Janssen mpc.jans...@gmail.comwrote:
I would just like to add that fossil already has a defined API in the
sense that what a fossil repo and server are is described in
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and
On Wed, Jul 24, 2013 at 1:17 PM, Mark Janssen mpc.jans...@gmail.com wrote:
Synchronisation and authentication is definitely not a app-level detail
for a DVCS, the actual transport used could be though.
In fossil's case authentication is (currently) largely an app-level detail.
The core bits
On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu arcf...@sacrideo.us wrote:
I’ve so far managed to avoid using the feature myself, but I have been on
teams where people tried to use this to some effect, and unfortunately, the
interfaces always seemed to scale very poorly. That’s not to say that
On Tue, 23 Jul 2013 10:29:36 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu arcf...@sacrideo.us wrote:
I’ve so far managed to avoid using the feature myself, but I have been
on
teams where people tried to use this to some effect, and
On Tue, 23 Jul 2013 11:03:09 +0200
j. van den hoff veedeeh...@googlemail.com wrote:
[...]
While the Lua scripting enabled me to gain a level of
sophistication and relative rigor in the process more than what I
could get from normal UNIX
plumbing, if my project wasn’t in Lua in the first
On Tue, 23 Jul 2013 11:29:32 +0200, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On Tue, 23 Jul 2013 11:03:09 +0200
j. van den hoff veedeeh...@googlemail.com wrote:
[...]
While the Lua scripting enabled me to gain a level of
sophistication and relative rigor in the process
Hi,
Not aimed at anyone in particular, but if you are going to suggest a
particular language, can you please point to an interpreter that is easily
embeddable into fossil? That seems to be the problem with at least JS and
Python, and seems to be Lua's strong point. There's no point in discussing
On Tue, Jul 23, 2013 at 12:51 PM, Laurens Van Houtven _...@lvh.io wrote:
Not aimed at anyone in particular, but if you are going to suggest a
particular language, can you please point to an interpreter that is easily
embeddable into fossil? That seems to be the problem with at least JS and
On Tue, Jul 23, 2013 at 7:57 PM, Aaron W.Hsu arcf...@sacrideo.us wrote:
With regards to scripting and fossil as a separate library, I actually see
these as separate things. Having Fossil as a separate library allows other
programs to use fossil capabilities, while any scripting interface, such
On Tue, Jul 23, 2013 at 8:20 PM, Stephan Beal sgb...@googlemail.com wrote:
Yes, there has been some confusion about the whole which scripting
language? topic. The fact is, once we have a library, anyone can tie any
amendment... scripting, to me, is important mainly because it provides an
Dear Stephan:
Thanks for the response. I think I’m a little confused about what the intended
use cases for a scripting language are? When I think of scripting the Fossil
SCM I’m envisioning like post and pre-commit hooks, or adding support for a
different sort of Wiki format, or integrating a
On Tue, Jul 23, 2013 at 8:28 PM, Aaron W.Hsu arcf...@sacrideo.us wrote:
Thanks for the response. I think I’m a little confused about what the
intended use cases for a scripting language are?
Scriptability, more than anything, is simply a benchmark which says, this
app is extensible.
Dear Stephan:
Thanks for your explanation. I, of course, agree that there are plenty of
interesting benefits that one gains from having a fossil(3) in addition to a
fossil(1). On the other hand, my initial email and my comments have nothing to
do with a fossil(3) interface. What I’ve been
On Tue, Jul 23, 2013 at 9:07 PM, Aaron W.Hsu arcf...@sacrideo.us wrote:
distinguish these use cases and the technical solutions that present
themselves for these cases. Everything you’ve mentioned in your previous
email related directly to how one might have access to fossil within
another
On Tue, Jul 23, 2013 at 5:29 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
[...]
But please don't also miss out a first-hand experience of someone who
implemented a well-visible program centered around Lua: [1], [2].
Personally, I find that minimality (of the runtime) is the
On Tue, Jul 23, 2013 at 4:29 AM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu arcf...@sacrideo.us wrote:
When fossil runs, it can dynamically link in any of the shared objects
that it finds there, and these can register additional functionality with
I think these things support each other. Specifically, with respect to Tcl
(and likely Guile, Lua), scripting support can come by embedding the Tcl
interpreter inside the app (ie: the standalone fossil executable), by
linking libtcl with fossil, and having fossil call into it appropriately.
Dear Stephan:
Here’s my attempt to define and clearly distinguish the various parts of this
discussion into a piece that might be useful for talking about these things in
the future. In my opinion, there are a few mutually orthogonal things to think
about:
The fossil API itself, which is
On Wed, Jul 24, 2013 at 12:12 AM, Ron Wilson ronw.m...@gmail.com wrote:
Seems to me it would act like a static binary unless requested to load one
or more shared libraries, only calling whatever hook services are
registered by the shared libraries. If no libraries are loaded, then the
binary
On Wed, Jul 24, 2013 at 1:32 AM, B Harder brad.har...@gmail.com wrote:
The first example would be Fossil with hooks, while the second would be
full scripting environment drives the operation, with full access to
fossil routines.
I'm personally more interested in the second.To my senses, it's
On Wed, Jul 24, 2013 at 1:55 AM, Aaron W.Hsu arcf...@sacrideo.us wrote:
against a fossil(3) library. This functionality can therefore be provided
by the fossil(1) executable program as well as from a separate shared
object against which the fossil(1) program links.
Right - that's just a
22 matches
Mail list logo
