Re: [fossil-users] authentication in JSON: anonymous vs. guest user
On Sun, Sep 11, 2011 at 12:55 AM, Stephan Beal sgb...@googlemail.comwrote: This question is primarily aimed at Richard, but anyone who's got some insight or opinions is of course free to chime in... As i understand it, the primary intention behind requiring the anonymous user login is to keep spiders from crawling the whole repo history, and the distinction between the two users is that anonymous gets hyperlinks and guest does not. In a JSON context, link-following is not an issue. There are no links... There should be links. Without them, the interface is not fully RESTful. See http://martinfowler.com/articles/richardsonMaturityModel.html for further information. A key idea behind REST is that an application can be given a small number of starter URLs and it can discover all the other URLs it requires by following links. , as such, in JSON docs - though individual JSON strings might incidentally contain HTML link strings, bots don't generically try to extract HTML text from JSON. Doing anything at all with the data requires writing an app-specific bot to do it. Given that, would be against fossil's nature if i reduce the JSON API's authentication to only 2 levels: read and write? Non-logged in users would be read-only and logged in would have write access only if their user profile allows it (and if it doesn't then logging in for JSON access doesn't have any benefit at all for the client). As far as i can see so far, the only ops which _need_ to be authenticated (for purposes of a JSON interface) are write-ops, and so far none of those are implemented. Commit, wiki-save, artifact-edit, etc., would be authenticated using the existing per-user permissions. Since spiders that follow JSON are not currently a problem, I think it would be OK to disregard the History permission on JSON-returning pages. Just keep in mind that at some point in the future, we might need to revisit this decision. So please don't paint us into a corner. :-? -- - 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 -- 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] Getting a check-in's info without an open checkout
On Sat, Sep 10, 2011 at 3:30 PM, Jeff Slutter j...@slutter.com wrote: (Via the command line interface...) The 'timeline' command can take a -R argument to specify a repository. It reports a set of information (time, user, check-in id, comment, etc.), but I do not see it reporting the parent(s) of a check-in The 'info' command can take an object (for example, a check-in's sha1) and report various information about it. If you give it a check-in's id, you can see the list of parents to that check-in. However, the 'info' command does not allow for a -R argument to specify a repo, it will only accept a check-in sha1 if you are from within an open checkout. It should be a legal operation to get the info of a check-in within a repository, without having to be in an open checkout (as is my situation), but I can not find the command line voodoo to get it. Am I missing something? In the end, I just need to get the list of parent check-ins for a check-in, without being in an open checkout folder, so by specifying the repository path. Does anyone know any way I can just get this information? A Fossil repository is an SQLite database. Your program can get any kind of information like this that it needs by querying the Fossil repository database directly. Information about the repository schema can be found here: http://www.fossil-scm.org/fossil/artifact/d72b7cf5aa06 To find parent/child relationships, you'll want to query the PLINK table. Thanks, Jeff ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] Presentation slides for Fossil?
On 09/10/11 15:54, Ron Wilson wrote: On Thu, Sep 8, 2011 at 4:08 PM, Ingo Kochingo.k...@gmx.de wrote: Take a look at http://arnebachmann.pytalhost.de/pdf/integrated-version-control-with-fossil-scm.pdf Good presentation. I noted it said that configuration is not shared. Actually, it is possible to share configuration between Fossil instances. It wrongly claims that fossil is GPL. -Martin ___ 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] Presentation slides for Fossil?
On Mon, Sep 12, 2011 at 09:48:01AM -0400, Martin S. Weber wrote: On 09/10/11 15:54, Ron Wilson wrote: On Thu, Sep 8, 2011 at 4:08 PM, Ingo Kochingo.k...@gmx.de wrote: Take a look at http://arnebachmann.pytalhost.de/pdf/integrated-version-control-with-fossil-scm.pdf Good presentation. I noted it said that configuration is not shared. Actually, it is possible to share configuration between Fossil instances. It wrongly claims that fossil is GPL. -Martin Fossil was originally licensed under the GPL. When that presentation was given in 2009 sharing configurations was not possible and the codebase was GPL. -- James Turner ja...@calminferno.net signature.asc Description: Digital signature ___ 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] Presentation slides for Fossil?
On Sep 12, 2011, at 3:48 PM, Martin S. Weber wrote: It wrongly claims that fossil is GPL. Rightly - at the time it was given... Fossil got relicensed some time ago. IIRC some code needed to be dropped due to that. See: http://fossil-scm.org/index.html/timeline?r=clear-title 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] Presentation slides for Fossil?
On Mon, Sep 12, 2011 at 3:55 PM, James Turner ja...@calminferno.net wrote: On Mon, Sep 12, 2011 at 09:48:01AM -0400, Martin S. Weber wrote: On 09/10/11 15:54, Ron Wilson wrote: ... I noted it said that configuration is not shared. Actually, it is possible to share configuration between Fossil instances. It wrongly claims that fossil is GPL. Hi, all! Yes, several of the presentations people have posted in response (both on- and off-list) have a few dated infos, but nonetheless they're a huge help and i own a big thanks to those (5, i think) of you who have sent me links to existing presentations. i'll almost certainly be using slides from each of them (so it might look likea a FrankenODP[1]), and i will post the results once i have something. It is likely to be several weeks before the copy/paste session begins, however (because working on the JSON code is more fun). [1] - Windows users: FrankenPPT -- - 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] authentication in JSON: anonymous vs. guest user
On Mon, Sep 12, 2011 at 1:26 PM, Richard Hipp d...@sqlite.org wrote:
There should be links. Without them, the interface is not fully RESTful.
See http://martinfowler.com/articles/richardsonMaturityModel.html for
further information. A key idea behind REST is that an application can be
given a small number of starter URLs and it can discover all the other
URLs it requires by following links.
That assumes, though, that the clients understand HTML. If the data which is
currently provided as links were provided differently then we might be
helping non-HTML apps rather than hindering them. For example...
(spontaneous idea, not something i've yet tried...)
Commit message: merged with version [abacab] and cherrypicked [defdef].
One idea for the JSON impl would be to run that text through a different
parser, which translates it into a compound object containing:
a) The original commit string (unparsed).
a.5) possibly also the HTML-parsed form.
b) elements describing the links.
Just off the top of my head, something like:
{
plain: merged with version [abacab] and cherrypicked [defdef].,
html: merged with version ...whatever the web interface shows...,
references: [abcacab, defdef]
}
or:
...
references: [/json/vinfo/abcacab, /json/vinfo/defdef]
That might improve the discoverability aspect while also not directly
hindering non-HTML clients.
Since spiders that follow JSON are not currently a problem, I think it would
be OK to disregard the History permission on JSON-returning pages. Just
keep in mind that at some point in the future, we might need to revisit this
decision. So please don't paint us into a corner.
As the other answers to my original post pointed out, my initial vision of
authentication was kinda 1969, free access for all, and was obviously
way-oversimplified. i'm punting on the auth problem for the time being in
order to look closely at fossil's impl to figure out how best i can
integrate with/to it. i don't want to rush into an impl, because
authentication as a problem domain is a minefield. Fossil's model is just
fine, i just need to figure out how to mesh with it.
--
- 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] authentication in JSON: anonymous vs. guest user
On Mon, Sep 12, 2011 at 11:33 AM, Stephan Beal sgb...@googlemail.comwrote:
On Mon, Sep 12, 2011 at 1:26 PM, Richard Hipp d...@sqlite.org wrote:
There should be links. Without them, the interface is not fully RESTful.
See http://martinfowler.com/articles/richardsonMaturityModel.html for
further information. A key idea behind REST is that an application can be
given a small number of starter URLs and it can discover all the other
URLs it requires by following links.
That assumes, though, that the clients understand HTML. If the data which
is currently provided as links were provided differently then we might be
helping non-HTML apps rather than hindering them. For example...
(spontaneous idea, not something i've yet tried...)
Anchor tags in HTML are just one mechanism for providing hyperlinks. In
JSON, you could just as easily invent an alternative mechanism. Perhaps an
object:
{
LinkType: Next,
URI: http://www.fossil-scm.org/fossil/json/timeline?first=12345;
}
So, for example, the JSON that comes back from a timeline request might
include multiple links such as the above that describe how to get the
previous or next timeline, or a longer timeline, or timelines for specific
branches, and so forth. The idea is that resources can move around (move to
different URLs) and the client-side application doesn't need to know about
it. As long as the starting URLs are the same, the client will discover the
other URLs automatically.
I'm not saying this is necessarily the best way to do things. But it is the
RESTful way to do things.
Commit message: merged with version [abacab] and cherrypicked [defdef].
One idea for the JSON impl would be to run that text through a different
parser, which translates it into a compound object containing:
a) The original commit string (unparsed).
a.5) possibly also the HTML-parsed form.
b) elements describing the links.
Just off the top of my head, something like:
{
plain: merged with version [abacab] and cherrypicked [defdef].,
html: merged with version ...whatever the web interface shows...,
references: [abcacab, defdef]
}
or:
...
references: [/json/vinfo/abcacab, /json/vinfo/defdef]
That might improve the discoverability aspect while also not directly
hindering non-HTML clients.
Since spiders that follow JSON are not currently a problem, I think it
would be OK to disregard the History permission on JSON-returning pages.
Just keep in mind that at some point in the future, we might need to revisit
this decision. So please don't paint us into a corner.
As the other answers to my original post pointed out, my initial vision of
authentication was kinda 1969, free access for all, and was obviously
way-oversimplified. i'm punting on the auth problem for the time being in
order to look closely at fossil's impl to figure out how best i can
integrate with/to it. i don't want to rush into an impl, because
authentication as a problem domain is a minefield. Fossil's model is just
fine, i just need to figure out how to mesh with it.
--
- 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
--
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] authentication in JSON: anonymous vs. guest user
On Mon, Sep 12, 2011 at 5:50 PM, Richard Hipp d...@sqlite.org wrote:
Anchor tags in HTML are just one mechanism for providing hyperlinks. In
JSON, you could just as easily invent an alternative mechanism. Perhaps an
object:
{
LinkType: Next,
URI: http://www.fossil-scm.org/fossil/json/timeline?first=12345
}
That looks good.
@Anyone who's got ideas for how to best represent stuff like that, feel free
to chime in. This doesn't just apply to the timeline, but potentially to any
page which presents detail links (as opposed to the nav links in the page
header and whatnot).
We should probably come with with a common set of data types/structures for
re-use throughout the API, e.g. hyperlinks, user information, wiki pages,
etc. So far i've just been ad-hoc'ing it and there haven't yet been any
shared types/structures except timestamps (for which i use Unix Epoch GMT,
for portability). There eventually will be a need for several common/shared
structures, though.
I'm not saying this is necessarily the best way to do things. But it is the
RESTful way to do things.
i'm not experienced enough with apps like this to suggest any best
practices, so keep the ideas coming. :)
--
- 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] First Fossil/REST proto-demo
On Sun, Sep 11, 2011 at 12:23 AM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Sep 11, 2011 at 4:19 AM, Clark Christensen cdcmi...@yahoo.com wrote: In my experience writing both JSON web services (in Perl), and the consumers of those services, sometimes you can get output that contains not only a JSON string, but stray newlines or other (debugging?) output. I'm sure you and Fossil would never do such a thing, right? Then again, anything's possible (useful debugging output, ISP-modified content, etc.) found that surrounding the JSON string with a predefined tag (I've standardized on TJSON/TJSON; because my company's name starts with T, but Text-JSON works, too) makes it easy to extract the JSON string from whatever else might be in the response content. But it also makes it invalid JSON. :-? Both yes and no. Clark is talking about encapsulating the JSON to protect it from problems introduced by outside factors. In my own experience with my personal website, I have found that some service providers (not my web hosting provider, but ISPs between the web host and the browser), inject their own content into anything that looks like text regardless of the file extension or MIME type. One possible work-around to this is to always use HTTPS, however my hosting provider charges extra for this due to the extra CPU load required. Though a Fossil server hosted on your own hardware could do this without incuring a surcharge. The solution I use is similar to Clark's. I wrap otherwise plain text content in HTML to give these injectors a place to put their junk. Otherwise, they inject where ever they think is a good place , which makes a mess. (This is for coontent intended to be viewable in the browser; for downloadable content, I put that in ZIP files.) So yes, the full response from the server is not pure JSON, however, the pure JSON can be extracted from between the tags that contain it. While this does add a step before the JSON can be parsed, it does reduce the risk that the JSON content is tainted. While the HTTPS work-around is certainly preferable, not everyone has the luxury of this option. ___ 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] First Fossil/REST proto-demo
On Mon, Sep 12, 2011 at 7:01 PM, Ron Wilson ronw.m...@gmail.com wrote: In my own experience with my personal website, I have found that some service providers (not my web hosting provider, but ISPs between the web host and the browser), inject their own content into anything that looks like text regardless of the file extension or MIME type. Wow. That's new to me. i'm honestly truly shocked by that, and would loudly protest/boycott/fire any provider which injected contents which effectively corrupted any of my data. Maybe i've just had exceedingly good luck with hosters so far. Such behaviour would break every single doc affected by it, so i can't see how it can have a positive business effect for any network provider. Sounds like a short-lived marketing idea to me. So yes, the full response from the server is not pure JSON, however, the pure JSON can be extracted from between the tags that contain it. While this does add a step before the JSON can be parsed, it does reduce the risk that the JSON content is tainted. If these evil ISPs can and do inject/modify even a single byte in the body/content, none of the contents can be trusted, IMO. They can add all the new headers they want, but changing the body? While the HTTPS work-around is certainly preferable, not everyone has the luxury of this option. i don't :( -- - 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] First Fossil/REST proto-demo
On 9/12/2011 1:01 PM, Ron Wilson wrote: In my own experience with my personal website, I have found that some service providers (not my web hosting provider, but ISPs between the web host and the browser), inject their own content into anything that looks like text regardless of the file extension or MIME type. I've heard of [free] web hosts that would add advertisements to your content, and I've heard of filtering proxies that would add stuff to your content [to assure you that you're protected!], and I've heard of server worms that would add content to pages, and desktop viruses and browser extensions that would add to web content (to show you more ads or install other malware or other BS). Some of these wouldn't plausibly affect a JSON web service, but I'll buy that some could. HOWEVER, the mere fact that wrapping JSON in a bogus tag protected it from a horribly misbehaved system in the case Clark knows about is no guarantee that it would help in other cases. If you abandon the assumption that HTTP mostly works, on what basis could you possibly decide where to stop in defensively designing this? (Even HTTPS isn't enough--some people live with networks that by design man-in-the-middle all HTTPS connections.) I would strongly oppose breaking compatibility with every JSON processor in the world (and, frankly, looking like idiots to people curious about fossil's web services) to possibly protect against some badly behaved proxies. A cool thing about open source is that people with batshit crazy environments can tweak a system so it works for them if they really can't fix their environment. I'm happy that open source can help people who live with crazy, but I don't want it to make me live with crazy. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] First Fossil/REST proto-demo
On Mon, Sep 12, 2011 at 8:36 PM, Joshua Paine jos...@letterblock.comwrote: I would strongly oppose breaking compatibility with every JSON processor in the world (and, frankly, looking like idiots to people curious about fossil's web services) to possibly protect against some badly behaved proxies. A cool thing about open source is that people with batshit crazy environments can tweak a system so it works for them if they really can't fix their environment. I'm happy that open source can help people who live with crazy, but I don't want it to make me live with crazy Amen and halleluja, brother! -- - 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] Ignoring CVS/*
Hi, Is there any way I can get fossil to ignore all the CVS directories and anything under it? I can't seem to get ignore-glob to do anything useful here. Thanks, Gé___ 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] Ignoring CVS/*
On 9/12/2011 4:01 PM, Gé Weijers wrote: Is there any way I can get fossil to ignore all the CVS directories and anything under it? I can't seem to get ignore-glob to do anything useful here. /CVS/*,*/CVS/* should do it -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Getting a check-in's info without an open checkout
Jeff Slutter jeff@... writes: (Via the command line interface...) The 'timeline' command can take a -R argument to specify a repository. It reports a set of information (time, user, check-in id, comment, etc.), but I do not see it reporting the parent(s) of a check-in ... Thanks, Jeff I have a bash script called 'fslinfo' that looks like this ... #!/bin/bash fossil open --keep $1 /dev/null 21 fossil info $2 fossil close --force /dev/null 21 ... it might work for you? /Jousef ___ 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] Getting a check-in's info without an open checkout
On 9/12/2011 4:15 PM, Jousef Lofstrom wrote: I have a bash script called 'fslinfo' that looks like this ... #!/bin/bash fossil open --keep $1 /dev/null 21 fossil info $2 fossil close --force /dev/null 21 ... it might work for you? /Jousef Thank you for the bash goodness. I ended up adding support for -R|--repository to the 'info' command, so you can query artifact information of a repository without being in an open checkout. I have sent the diff for the change to Dr. Hipp, and also mailed off a CA to him. Hopefully the patch is deemed acceptable for inclusion. -Jeff ___ 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] First Fossil/REST proto-demo
On Mon, Sep 12, 2011 at 8:36 PM, Joshua Paine jos...@letterblock.com wrote: I would strongly oppose breaking compatibility with every JSON processor in the world (and, frankly, looking like idiots to people curious about fossil's web services) to possibly protect against some badly behaved I am surprised that none of the major JSON parsers would not have any means (either directly or by being called by an XML/HTML parser) to process JSON embedded inside XML or HTML. Ultimately, I agree it should not be necessary to resort to such schemes as a means to work around bad behavior. Nevertheless, I find it hard to imagine that noone would never come up with a legitimate reason to embed JSON into XML or HTML. If Javascript can be embedded in a webpage, why not JSON? FYI, where I work, we are required to code defensively, so I have acquired a tendancy to look for problems so I can better defend against them. Nothing's perfect, of course. ___ 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] First Fossil/REST proto-demo
On 9/12/2011 6:11 PM, Ron Wilson wrote: I am surprised that none of the major JSON parsers would not have any means (either directly or by being called by an XML/HTML parser) to process JSON embedded inside XML or HTML. JSON can be embedded in HTML, but to do this reliably, you must do a lot more unicode and HTML character escaping than is necessary for serving plain JSON. Rails will output JSON formatted that way since some version (but not since always), and PHP added the capability to their encoder in 5.2 or 5.3. The only decoders I know that can natively handle such JSON embedded in HTML are, of course, web browsers. But the parsers for web browsers are monsters, and JSON is designed to be extremely simple to parse. And JSON inside HTML has no inherent meaning--the HTML context obscures the simple here's-an-object concept--so of course what's really happening is that JSON in HTML is plain old JavaScript. Without accompanying code (an assignment statement, at a minimum), it does nothing and means nothing. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] authentication in JSON: anonymous vs. guest user
On Mon, Sep 12, 2011 at 11:50 AM, Richard Hipp d...@sqlite.org wrote:
Anchor tags in HTML are just one mechanism for providing hyperlinks. In
JSON, you could just as easily invent an alternative mechanism. Perhaps an
object:
{
LinkType: Next,
URI: http://www.fossil-scm.org/fossil/json/timeline?first=12345;
}
I would add LinkDescription:description to that, or possibly
LinkDescription:URL, but usually the description would be short
enough to not worry about. Also, it would not, for example, be
unreasonable for the description to be the short description of a
ticket, even or commit.
___
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] authentication in JSON: anonymous vs. guest user
On Tue, Sep 13, 2011 at 12:35 AM, Ron Wilson ronw.m...@gmail.com wrote: I would add LinkDescription:description to that, or possibly LinkDescription:URL, but usually the description would be short enough to not worry about. Also, it would not, for example, be unreasonable for the description to be the short description of a ticket, even or commit. That actually touches on my original point - if we have Ticket JSON objects, we don't much need to transmit ticket links because the links can be generated from the objects (if needed). A client also gains little (i suspect) from having the JSON API send links to non-JSON pages (which he probably can't use via this client app). To re-use the initial example of artifact links in commit messages: the JSON API(s) which return such messages would want to provide a link to the JSON method for fetching those links, as opposed to linking to the HTML variants. One problematic area in that regard, however, is wiki content. It is, by nature, HTML. i would like to include an option to return raw or parsed wiki pages (provided that isn't a potential security issue), but it wouldn't be practical to parse the wiki page as a DOM-like JSON structure, so we would deliver it like fossil does now (with the option to return it in raw/unparsed form). -- - 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] First Fossil/REST proto-demo
On Tue, Sep 13, 2011 at 12:11 AM, Ron Wilson ronw.m...@gmail.com wrote: reason to embed JSON into XML or HTML. If Javascript can be embedded in a webpage, why not JSON? As a point of trivia: the JSON grammar allows, but does not require, that forward-slash characters be escaped by a backslash. The reason for this IS the embedding in HTML (Doug Crockford responded to my query about the reason for escaping /). If you have \/... in JSON inside HTML, it doesn't confuse the HTML page like non-escaping it does. FYI, where I work, we are required to code defensively, so I have acquired a tendancy to look for problems so I can better defend against them. Nothing's perfect, of course. i'd never heard of this particular problem until today. -- - 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] First Fossil/REST proto-demo
On Tue, Sep 13, 2011 at 12:48 AM, Stephan Beal sgb...@googlemail.comwrote: As a point of trivia: the JSON grammar allows, but does not require, that ... i just stumbled upon the original post (which i had saved in my JSON C code): From: Douglas Crockford doug...@crockford.com To: Stephan Beal sgb...@googlemail.com Subject: Re: Is escaping of forward slashes required? It is allowed, not required. It is allowed so that JSON can be safely embedded in HTML, which can freak out when seeing strings containing /. JSON tolerates \/ for this reason. On 4/8/2011 2:09 PM, Stephan Beal wrote: Hello, Jsonites, i'm a bit confused on a small grammatic detail of JSON: if i'm reading the grammar chart on http://www.json.org/correctly, forward slashes (/) are supposed to be escaped in JSON. However, the JSON class provided with my browsers (Chrome and FF, both of which i assume are fairly standards/RFC-compliant) do not escape such characters. Is backslash-escaping forward slashes required? If so, what is the justification for it? (i ask because i find it unnecessary and hard to look at.) -- -- - 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
