Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 02:14:38AM +0200, Stephan Beal wrote: > Hi, all! > > Another minor milestone: the 2nd proof-of-concept non-HTML client, this time > in Java. It's fairly basic, and only supports synchronous operation, but > it's a start. Sorry, not that I care much about JSON, but can json be used in a way that a program *spawns* fossil and talks to it using json, until it decides it's enough and fossil stops? The little I read about the json implementation in fossil, it sounds to me simply as RPC over http, so requiring a server ready listening at a known address. Regards, Lluís ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
2011/10/1 Lluís Batlle i Rossell > Sorry, not that I care much about JSON, but can json be used in a way that > a > program *spawns* fossil and talks to it using json, until it decides it's > enough and fossil stops? > In theory, yes. It just has to start fossil server --port XYZ, send its requests to localhost:XYZ/json/..., and kill of the spawned process when it's done (because the server mode forks before json mode is entered, i don't think i could add a json command to shut down the server). The little I read about the json implementation in fossil, it sounds to me > simply as RPC over http, so requiring a server ready listening at a known > address. > That's basically the case, yes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 11:12:51AM +0200, Stephan Beal wrote: > 2011/10/1 Lluís Batlle i Rossell > > > Sorry, not that I care much about JSON, but can json be used in a way that > > a > > program *spawns* fossil and talks to it using json, until it decides it's > > enough and fossil stops? > > > > In theory, yes. It just has to start fossil server --port XYZ, send its > requests to localhost:XYZ/json/..., and kill of the spawned process when > it's done (because the server mode forks before json mode is entered, i > don't think i could add a json command to shut down the server). But that's only a hack. The spawner will not know when the server will be listening. And killing it, will not know if anyone else uses it and it is working. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
2011/10/1 Lluís Batlle i Rossell > But that's only a hack. The spawner will not know when the server will be > listening. And killing it, will not know if anyone else uses it and it is > working. i don't see any other way to do it unless/until fossil is split up into a lib. The only entry points clients currently have into fossil are via CLI or HTTP modes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 11:23:32AM +0200, Stephan Beal wrote: > 2011/10/1 Lluís Batlle i Rossell > > > But that's only a hack. The spawner will not know when the server will be > > listening. And killing it, will not know if anyone else uses it and it is > > working. > > > i don't see any other way to do it unless/until fossil is split up into a > lib. The only entry points clients currently have into fossil are via CLI or > HTTP modes. Maybe you could do some http-over-stdin/stdout, and speak json there. :) I think of people wanting to write frontends to fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
I thought that was how fossil over ssh works already; on the far end fossil is started with some undocumented private command that talks http over stdin/stdout. you may well find your JSON work works transparently with that mechanism too due to it being baked into the fossil http stack! Sent from my BlackBerry® wireless device -Original Message- From: Lluís Batlle i Rossell Sender: fossil-users-boun...@lists.fossil-scm.org Date: Sat, 1 Oct 2011 11:28:39 To: Reply-To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] minor milestone: Java client On Sat, Oct 01, 2011 at 11:23:32AM +0200, Stephan Beal wrote: > 2011/10/1 Lluís Batlle i Rossell > > > But that's only a hack. The spawner will not know when the server will be > > listening. And killing it, will not know if anyone else uses it and it is > > working. > > > i don't see any other way to do it unless/until fossil is split up into a > lib. The only entry points clients currently have into fossil are via CLI or > HTTP modes. Maybe you could do some http-over-stdin/stdout, and speak json there. :) I think of people wanting to write frontends to fossil. ___ 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
Re: [fossil-users] minor milestone: Java client
2011/10/1 Lluís Batlle i Rossell > Maybe you could do some http-over-stdin/stdout, and speak json there. :) > > I think of people wanting to write frontends to fossil. > i was just thinking about that while i was out shopping. It is, in principal, possible, but fossil's heavy use of exit() as an error recovery strategy would interfere with that. After every command fossil runs, exit() is called somewhere, which makes it difficult or impossible to chain commands together in the same app session. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
> Maybe you could do some http-over-stdin/stdout, and speak json there. :) Isn't "fossil cgi" already doing that? A front-end could build the appropriate environment variables and fork/exec "fossil cgi", feeding the post body to fossil's stdin. Actually, I was thinking that http/json was a more modern and universal API for doing a fossil lib than an API based on a long list of C functions and structs. > after every command fossil runs, exit() is called somewhere, which makes it > difficult or impossible to chain commands together in the same app session. Why? Paul On 1 Oct 2011, at 13:42 , Stephan Beal wrote: > 2011/10/1 Lluís Batlle i Rossell > Maybe you could do some http-over-stdin/stdout, and speak json there. :) > > I think of people wanting to write frontends to fossil. > > i was just thinking about that while i was out shopping. It is, in principal, > possible, but fossil's heavy use of exit() as an error recovery strategy > would interfere with that. After every command fossil runs, exit() is called > somewhere, which makes it difficult or impossible to chain commands together > in the same app session. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > ___ > 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
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal wrote: > > Maybe you could do some http-over-stdin/stdout, and speak json there. :) > > Isn't "fossil cgi" already doing that? A front-end could build the > appropriate environment variables and fork/exec "fossil cgi", feeding the > post body to fossil's stdin. > That is basically what server mode does - prepares the cgi environment (including stdin/stdout) and runs it through CGI mode (where output is very controlled (entirely buffered) because no body text may be sent before the headers are sent). The majority of the parameter handling in all of the fossil commands relies on the environment having a fresh state for each request, which means the whole environment, GET, POST, and everything, needs to be reconstructed before each commands. e.g. the way a given command is invoked is based on the request path (an environment variable), which can only be set to one value for any given invocation of server/CGI mode. There is no mechanism (in the current code base) with which we can simply re-set the whole environment and run a different command. > Actually, I was thinking that http/json was a more modern and universal API > for doing a fossil lib than an API based on a long list of C functions and > structs. > In a way it is, but at the lowest level it's of course all C bits. But once we have a usable JSON API in place, the effect will basically be a "library used over the net" instead of one you link to directly. Not that i'm discounting the idea - it's fundamentally a good one (and could even allow json-over-ssh/rsh/whatever, as Alaric mentioned). But it won't work out of the box on the current code base. It is, however, something i will certainly keep in mind as the library gradually mutates in a direction where that would be feasible. > after every command fossil runs, exit() is called somewhere, which makes > it difficult or impossible to chain commands together in the same app > session. > > Why? > The same reason attempts to adding a shell mode for fossil have failed so far. Almost every error condition in fossil passes through fossil_fatal() or similar, and that ends up calling exit(). So if you add a command and use any of the db functions, and those hit any errors at all, your command will end up exit()ing. If you mean "why does it exit() so much?" That's just the way it was originally designed - historic momentum. For fossil's original purpose (and its current primary uses), the current model actually works quite well, and simplifies some of the trickier handling needed when producing HTML output (e.g. the buffering of the body and headers, and sending them out at the proper times). There is of course lots of interest in refactoring fossil into a library, but the amount of effort required is huge. It could easily take a few full-time weeks of development effort, and would probably require the assistance of at least one person who's "exceedingly familiar" with fossil's "more intricate bits" (e.g. how artifacts are maintained/linked/created/etc.). While i'm relatively familiar with the code in general, there are huge blocks of voodoo in there i won't touch for fear of breaking them. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 1, 2011 at 9:07 AM, Paul Ruizendaal wrote: > > > after every command fossil runs, exit() is called somewhere, which makes > it difficult or impossible to chain commands together in the same app > session. > > Why? > > I built Fossil using the old-school unix design paradigm of a light-weight process that does one thing quickly, then exits, leaving the OS clean up the mess. As long as the process is reasonably light-weight, this pattern works very, very well. No worries with memory leaks or threads or unwinding the stack following an error, or any of the other management issues that plague long-running processes. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On 1 Oct 2011, at 15:28 , Stephan Beal wrote:
> On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal wrote:
> > Maybe you could do some http-over-stdin/stdout, and speak json there. :)
>
> Isn't "fossil cgi" already doing that? A front-end could build the
> appropriate environment variables and fork/exec "fossil cgi", feeding the
> post body to fossil's stdin.
>
> That is basically what server mode does - prepares the cgi environment
> (including stdin/stdout) and runs it through CGI mode...
Yes, and this is what any wrapper program can do. For example, there are folks
that would like to have Tcl/Jim with Fossil, I would prefer Javascript and I'm
sure there are those who would like Python or PHP. In each of those
environments it would be easy to add a command/library function that calls
Fossil's json interface through exec'ing Fossil in cgi mode. Tcl etc. would be
wrapped around Fossil, rather than Fossil wrapped around the language and that
way everybody can have their preferred language without further bloat in the
Fossil binary.
Doing fork/exec sounds expensive, but on a posix box there is not much
difference between that and spawning a thread:
http://bulk.fefe.de/scalable-networking.pdf
> (where output is very controlled (entirely buffered) because no body text may
> be sent before the headers are sent). The majority of the parameter handling
> in all of the fossil commands relies on the environment having a fresh state
> for each request, which means the whole environment, GET, POST, and
> everything, needs to be reconstructed before each commands. e.g. the way a
> given command is invoked is based on the request path (an environment
> variable), which can only be set to one value for any given invocation of
> server/CGI mode. There is no mechanism (in the current code base) with which
> we can simply re-set the whole environment and run a different command.
Yes, and why would that be difficult to handle for a wrapper (see below)?
>
> > after every command fossil runs, exit() is called somewhere, which makes it
> > difficult or impossible to chain commands together in the same app session.
>
> Why?
>
> The same reason attempts to adding a shell mode for fossil have failed so
> far. Almost every error condition in fossil passes through fossil_fatal() or
> similar, and that ends up calling exit(). So if you add a command and use any
> of the db functions, and those hit any errors at all, your command will end
> up exit()ing. If you mean "why does it exit() so much?" That's just the way
> it was originally designed - historic momentum. For fossil's original purpose
> (and its current primary uses), the current model actually works quite well,
> and simplifies some of the trickier handling needed when producing HTML
> output (e.g. the buffering of the body and headers, and sending them out at
> the proper times). There is of course lots of interest in refactoring fossil
> into a library, but the amount of effort required is huge. It could easily
> take a few full-time weeks of development effort, and would probably require
> the assistance of at least one person who's "exceedingly familiar" with fos
sil's "more intricate bits" (e.g. how artifacts are
maintained/linked/created/etc.). While i'm relatively familiar with the code in
general, there are huge blocks of voodoo in there i won't touch for fear of
breaking them.
My questions was indeed the former: why do the calls to exit make it difficult
or impossible to chain commands -- there would simply be a chain of CGI calls
and if one step fails the wrapper has to decide what to do next, just as it
would have to do when a classic API call fails.
My question was not the latter ("why does it exit on exceptions"). Richard
calls it vintage unix thinking, but I think it is equally valid in a RESTfull
design -- perhaps any design.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 1, 2011 at 11:22 PM, Paul Ruizendaal wrote:
> ...Yes, and this is what any wrapper program can do. For example, there are
> folks that would like to have Tcl/Jim with Fossil, I would prefer Javascript
>
(me, too, but don't tell anyone ;)
Doing fork/exec sounds expensive, but on a posix box there is not much
> difference between that and spawning a thread:
> http://bulk.fefe.de/scalable-networking.pdf
i wasn't aware of that.
> Yes, and why would that be difficult to handle for a wrapper (see below)?
>
...My questions was indeed the former: why do the calls to exit make it
> difficult or impossible to chain commands -- there would simply be a chain
> of CGI calls and if one step fails the wrapper has to decide what to do
> next, just as it would have to do when a classic API call fails.
>
Implementing it as a wrapper hadn't occurred to me, actually. Yes, you're
right - such a wrapper could simply call fossil in succession. i actually
had a dream last night about a server mode which keeps a persistent
connection for the JSON streams, but that isn't doable with the current
architecture.
> My question was not the latter ("why does it exit on exceptions"). Richard
> calls it vintage unix thinking, but I think it is equally valid in a
> RESTfull design -- perhaps any design.
>
In application design, yes, but not in a library design. i would immediately
stop using any library which called exit(). Imagine if sqlite3 called exit
when an insert failed.
But your idea of a wrapper app would effectively turn fossil into a library
of sorts, and would "hide" the exits from clients.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote: > Doing fork/exec sounds expensive, but on a posix box there is not much > difference between that and spawning a thread: > http://bulk.fefe.de/scalable-networking.pdf Please don't base decisions on questionable micro-benchmarks. fork+exec is significantly more expensive than thread creation in a multi-processor environment. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 03:07:52PM +0200, Paul Ruizendaal wrote: > > Maybe you could do some http-over-stdin/stdout, and speak json there. :) > > Isn't "fossil cgi" already doing that? A front-end could build the > appropriate environment variables and fork/exec "fossil cgi", feeding the > post body to fossil's stdin. > > Actually, I was thinking that http/json was a more modern and universal API > for doing a fossil lib than an API based on a long list of C functions and > structs. Well, I don't agree with that. :) Libs and RPCs have each their own place in the software world. I still can remember how one I had to deal with a (so-called) 'library', that consisted of two single functions, that had a single "char *" parameter, that had to contain a big xml defining what to do. Now I can laugh about that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 01, 2011 at 09:55:36AM -0400, Richard Hipp wrote: > On Sat, Oct 1, 2011 at 9:07 AM, Paul Ruizendaal wrote: > > > > > > after every command fossil runs, exit() is called somewhere, which makes > > it difficult or impossible to chain commands together in the same app > > session. > > > > Why? > > > > > I built Fossil using the old-school unix design paradigm of a light-weight > process that does one thing quickly, then exits, leaving the OS clean up the > mess. As long as the process is reasonably light-weight, this pattern works > very, very well. No worries with memory leaks or threads or unwinding the > stack following an error, or any of the other management issues that plague > long-running processes. I agree with the design. Maybe there is still a way to map that with a stdin/stdout communication, tough. I don't know in detail. As for leaks, the memory leak about annotate was at every checkin traversed, though. Does the change in that branch look fine for a merge? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sun, Oct 2, 2011 at 11:58 AM, Joerg Sonnenberger wrote: > On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote: > > http://bulk.fefe.de/scalable-networking.pdf > > Please don't base decisions on questionable micro-benchmarks. fork+exec > is significantly more expensive than thread creation in a > multi-processor environment. i suspect that most of fossil's network use is CGI mode, not standalone server (or in local ui mode with a single user). The fork() only happens in server mode (which then spawns off into what we know as CGI mode), meaning that any migration from forking to threading would only happen in the server, and would add undue complication to code which is otherwise straightforward (and which doesn't have any need to scale to 1000 requests/second). @Paul: thanks for the article. It's a bit dated (2003), but nonetheless interesting. i can report that the fork() do not appear to be a problem at the level fossil operates. It is a special-purpose app, not a generic server serving arbitrary content. i.e. it gets fewer requests and when it gets a request it doesn't have to do much work to figure out what to do - the request path leads directly to C code instead of arbitrary content which must be figured out. My 32-bit netbook (1.6GHz Atom) regularly responds to fossil/json requests over CGI in under 50ms and my 64-bit laptop/workstation (2.4GHz Core2 Duo) averages under 20ms for most of the current JSON APIs (/json/stat in "full detail mode" can take several seconds on a large repo). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sun, Oct 02, 2011 at 11:58:33AM +0200, Joerg Sonnenberger wrote: > On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote: > > Doing fork/exec sounds expensive, but on a posix box there is not much > > difference between that and spawning a thread: > > http://bulk.fefe.de/scalable-networking.pdf > > Please don't base decisions on questionable micro-benchmarks. fork+exec > is significantly more expensive than thread creation in a > multi-processor environment. I think exec is not in the game, in fossil. OTH, process creation and destruction have to run, of course, much more code than thread creation and destruction. There is much more isolation and cleanup. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
2011/10/2 Lluís Batlle i Rossell > As for leaks, the memory leak about annotate was at every checkin > traversed, > though. Does the change in that branch look fine for a merge? Just to be clear - that's not the only leak in fossil. There many, many places where resources are left to be cleaned up by exit(). Every time you call cgi_set_content_type() or cgi_set_parameter() (e.g. to initialize the state for a new request), it's leaking (twice in cgi_set_parameter()). Fixing these requires not only calls to free(), but the infrastructure for tracking the memory which eventually needs to be freed. Maybe this sounds sacrilegious, but i currently think the easiest/best way to "fix" that type of thing (which would be needed for any library form of fossil) would be to re-implement it as libfossil2, building it as a library from the ground up and porting over the existing functionality one step at a time. It would _not_ be a 1-to-1 copy because all of the fossil features are currently monolithic, using shared static state and whatnot to communicate between internal routines (some of which would need to be made into lib-level routines). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sun, Oct 02, 2011 at 12:33:08PM +0200, Stephan Beal wrote: > 2011/10/2 Lluís Batlle i Rossell > > > As for leaks, the memory leak about annotate was at every checkin > > traversed, > > though. Does the change in that branch look fine for a merge? > > > Just to be clear - that's not the only leak in fossil. There many, many > places where resources are left to be cleaned up by exit(). Every time you > call cgi_set_content_type() or cgi_set_parameter() (e.g. to initialize the > state for a new request), it's leaking (twice in cgi_set_parameter()). > Fixing these requires not only calls to free(), but the infrastructure for > tracking the memory which eventually needs to be freed. Well, those are exactly the kind of leaks that can be forgotten about, thanks to fork(). I just wanted to state the difference about those and the 'annotate leak'. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
2011/10/2 Lluís Batlle i Rossell > Well, those are exactly the kind of leaks that can be forgotten about, > thanks to > fork(). They can be forgotten because of exit(), not fork(). fork() will duplicate leaked memory but exit() will clean it up. I just wanted to state the difference about those and the 'annotate > leak'. > Yes, it would be nice to see that fix include :) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sun, Oct 02, 2011 at 12:43:25PM +0200, Stephan Beal wrote: > They can be forgotten because of exit(), not fork(). fork() will duplicate > leaked memory but exit() will clean it up. Well, I meant that. > I just wanted to state the difference about those and the 'annotate > > leak'. > > > > Yes, it would be nice to see that fix include :) In that branch I changed some basic fossil functions, through the lots of troubles I found enabling an assertion in blob.c, as I explained in some messages to this list. I invite someone understanding clearly blob.c to review those, because I might have understood something wrong there. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
2011/10/2 Lluís Batlle i Rossell > messages to this list. I invite someone understanding clearly blob.c to > review those, because I might have understood something wrong there. > blob.c was actually the first code from fossil i studied really deeply (coming from the world of C++, i was amazed that this type of class just be done just as easily in C). >From what i've seen of your changes, e.g. 7ad4dfbe8b, everything looks correct to me. Because of your posts on the topic, i've been extra careful about using empty_blob to initialize blobs in the json code. There are easy mistakes to make when using blob, like the one you fixed here: http://www.fossil-scm.org/index.html/fdiff?v1=8a88d2e5834547b7&v2=67d8b25e0721992f -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sat, Oct 1, 2011 at 3:07 PM, Paul Ruizendaal wrote:
> Isn't "fossil cgi" already doing that? A front-end could build the
> appropriate environment variables and fork/exec "fossil cgi", feeding the
> post body to fossil's stdin.
>
How's this look... a first prototype at feeding POST data in via CLI mode...
[stephan@cheyenne:~/cvs/fossil/fossil-json]$ cat in.1
{
"requestId":"POST from file test",
"indent":2,
"payload":{
"limit":2
}
}
[stephan@cheyenne:~/cvs/fossil/fossil-json]$ ./fossil json timeline wi
--json-input - < in.1
{
"fossil":"6d0667831a0aa39f1bbf248f1869769b35463eea",
"timestamp":1317557990,
"requestId":"POST from file test",
"procTimeMs":1,
"payload":{
"limit":2,
"timeline":[
{
"rid":12811,
"uuid":"a7e68df71b95d35321b9d9aeec3c8068f991926c",
"timestamp":1310227825,
"comment":"Changes to wiki page [Apache On Windows XP]",
"user":"jeffrimko",
"eventType":"w"
},
{
"rid":12616,
"uuid":"108404df1226db92a4fbeeae173613d6c4a44699",
"timestamp":1308635729,
"comment":"Changes to wiki page [Cookbook]",
"user":"ron",
"eventType":"w"
}
]
}
}
There are some mismatches in argument handling in that mode (as we can see
from the "indent" request parameter not being honored), but that could be
fixed.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Sun, Oct 2, 2011 at 2:22 PM, Stephan Beal wrote:
> How's this look... a first prototype at feeding POST data in via CLI
> mode...
>
And here's a second attempt, the major improvement being that the command to
run can be specified in the POST data:
[stephan@cheyenne:~/cvs/fossil/fossil-json]$ cat in.2
{
"requestId":"POST from file test",
"command": "timeline/wiki",
"indent":2,
"payload":{
"limit":1
}
}
[stephan@cheyenne:~/cvs/fossil/fossil-json]$ ./fossil json --json-input in.2
{
"fossil":"8145cdbf3b167efcf304e4ec924aaf85fdfa072d",
"timestamp":1317559138,
"requestId":"POST from file test",
"procTimeMs":1,
"payload":{
"limit":1,
"timeline":[{
"rid":12811,
"uuid":"a7e68df71b95d35321b9d9aeec3c8068f991926c",
"timestamp":1310227825,
"comment":"Changes to wiki page [Apache On Windows XP]",
"user":"jeffrimko",
"eventType":"w"
}]
}
}
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On Oct 4, 2011, at 12:27 AM, Paul Ruizendaal wrote: > > On 2 Oct 2011, at 11:58 , Joerg Sonnenberger wrote: > >> On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote: >>> Doing fork/exec sounds expensive, but on a posix box there is not much >>> difference between that and spawning a thread: >>> http://bulk.fefe.de/scalable-networking.pdf >> >> Please don't base decisions on questionable micro-benchmarks. fork+exec >> is significantly more expensive than thread creation in a >> multi-processor environment. > > [...] > In any case, the cost of fork/exec would be less than 0.1 ms. As most Fossil > commands take much longer than that, I think the proposal is a practical > design for wrapping Fossil. Anyhow Fossil is doing only fork, which is pretty cheap. And, unless some crazy security folk take over, there is no reason to change this :) Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor milestone: Java client
On 2 Oct 2011, at 11:58 , Joerg Sonnenberger wrote: > On Sat, Oct 01, 2011 at 11:22:28PM +0200, Paul Ruizendaal wrote: >> Doing fork/exec sounds expensive, but on a posix box there is not much >> difference between that and spawning a thread: >> http://bulk.fefe.de/scalable-networking.pdf > > Please don't base decisions on questionable micro-benchmarks. fork+exec > is significantly more expensive than thread creation in a > multi-processor environment. Its not black and white, I think. The cost of fork/exec would only be relatively low on Posix for a statically linked binaries with a small working set that are already in memory (as to minimize copy on write, TLB updates etc.). On windows it might be quite different. I've not found any measurements on threads vs. forks in multiprocessor environments. I guess results would depend on the size of the binaries involved. For x86 it would probably depend on chip manufacturer, as AMD's cache design is different from Intel's design. In any case, the cost of fork/exec would be less than 0.1 ms. As most Fossil commands take much longer than that, I think the proposal is a practical design for wrapping Fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
