On Fri, Sep 16, 2011 at 5:07 AM, Ron Wilson wrote:
> A simplification on templates would be a list of fields in the desired
> order. Since most of the JSON responses would be lists of fields and
> their values, this would achieve nearly all that templates could.
> (True, some fields do have compl
On Thu, Sep 15, 2011 at 8:32 AM, fossil-m...@h-rd.org
wrote:
> I think including links etc. gets baroque pretty fast, and different use
> cases require different links. It may be better in the long run to simply
> add a kind of template mechanism to the server. This is explained on p. 297
> in "
Hi,
the template approach in my last post could also be used for the wsdl
stuff mentioned in another thread about json.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossi
On Thu, Sep 15, 2011 at 2:32 PM, fossil-m...@h-rd.org
wrote:
> I think including links etc. gets baroque pretty fast, and different use
i think i would have used the word "painful", but baroque is more colorful.
> cases require different links. It may be better in the long run to simply
> add
On Tue, Sep 13, 2011 at 10:30 AM, Alaric Snell-Pym
wrote:
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
"parents" : {
"" : { "json" : "http://..json";, "html"
: "http://...html"; },
"" : { "json" :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2011 04:24 PM, Ron Wilson wrote:
> On Tue, Sep 13, 2011 at 4:30 AM, Alaric Snell-Pym
> wrote:
>> by context, but it might be worth including JSON and human-HTML versions
>> of each URL, like so:
>>
>> {
>> ...stufff about a commit...
>> "
On Tue, Sep 13, 2011 at 5:35 PM, Ron Wilson wrote:
> Raw delivery of wiki pages is an issue of its own. I have not yet
> looked into that, as I have been able to make do with surounding the
> wiki content with ... (which I mentioned in a post
> some while back).
>
i've had similar frustrations
On Mon, Sep 12, 2011 at 6:44 PM, Stephan Beal wrote:
> On Tue, Sep 13, 2011 at 12:35 AM, Ron Wilson wrote:
>>
>> I would add "LinkDescription":"description" to that, or possibly
>> "LinkDescription":"URL", but usually the description would be short
>
> That actually touches on my original point -
On Tue, Sep 13, 2011 at 4:30 AM, Alaric Snell-Pym
wrote:
> by context, but it might be worth including JSON and human-HTML versions
> of each URL, like so:
>
> {
> ...stufff about a commit...
> "parents" : {
> "" : { "json" : "http://..json";, "html"
> : "http://...html"; },
> ""
On Tue, Sep 13, 2011 at 10:30 AM, Alaric Snell-Pym
wrote:
> by context, but it might be worth including JSON and human-HTML versions
> of each URL, like so:
>
> {
> ...stufff about a commit...
> "parents" : {
> "" : { "json" : "http://..json";, "html"
> : "http://...html"; },
> "
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/12/2011 05:07 PM, Stephan Beal wrote:
> On Mon, Sep 12, 2011 at 5:50 PM, Richard Hipp wrote:
>
>> Anchor tags in HTML are just one mechanism for providing hyperlinks. In
>> JSON, you could just as easily invent an alternative mechanism. Perhap
On Tue, Sep 13, 2011 at 12:35 AM, Ron Wilson 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 th
On Mon, Sep 12, 2011 at 11:50 AM, Richard Hipp 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.o
On Mon, Sep 12, 2011 at 5:50 PM, Richard Hipp 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.o
On Mon, Sep 12, 2011 at 11:33 AM, Stephan Beal wrote:
> On Mon, Sep 12, 2011 at 1:26 PM, Richard Hipp 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
On Mon, Sep 12, 2011 at 1:26 PM, Richard Hipp 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 num
On Sun, Sep 11, 2011 at 12:55 AM, Stephan Beal wrote:
> 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 cr
On Sun, Sep 11, 2011 at 3:50 PM, Weber, Martin S wrote:
> Right now for the fossil repository itself, I can read & write some stuff,
> but I cannot read everything. For example, I cannot read the complete list
> of users.
You're right. The only multi-user repo i work on is fossil's, so i was
ign
Right now for the fossil repository itself, I can read & write some stuff, but
I cannot read everything. For example, I cannot read the complete list of
users. So the sentence "As far as i can see so far, the only ops which _need_
to be authenticated (for purposes of a JSON interface) are write-
On Sun, Sep 11, 2011 at 10:00 AM, Ben Summers wrote:
> Private repositories will need the user to authenticate to get read only
> access.
>
Doh, i completely didn't think of that. You're right.
> I trust you're planning to respect the permissions for the anonymous user?
>
>
i am now!
--
On 11 Sep 2011, at 05:55, Stephan Beal wrote:
>
> In a JSON context, link-following is not an issue. There are no 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 a
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 t
22 matches
Mail list logo
