Re: [fossil-users] authentication in JSON: anonymous vs. guest user
On Fri, Sep 16, 2011 at 5:07 AM, Ron Wilson ronw.m...@gmail.com 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 complex values, but a field list should be simple to implement and would be a good next step) i've seen SOAP APIs where for some requests the user supplies the list of fields to include or (in some cases) exclude from the result. That would certainly be a simpler first step than implementing a template parser. -- - 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 Tue, Sep 13, 2011 at 10:30 AM, Alaric Snell-Pym
alaric-ijh4firwi8dzyd0pdsz...@public.gmane.orgwrote:
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
parents : {
hash of parent commit : { json : http://..json;, html
: http://...html; },
hash of parent commit : { json : http://..json;, html
: http://...html; }
}
}
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 Effective Tcl/Tk Programming by M. Harrison
and M. McLennan. Basically the client sends a request giving a
template and the data it wants. This allows each client to get fossil
data in the format the client needs, with just the data fields it
needs. So a client could request just the title of a ticket, or just
the contents.
http://.../ticket.json{title+:+$title} as an example
___
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 Thu, Sep 15, 2011 at 2:32 PM, fossil-m...@h-rd.org
fossil-m...@h-rd.orgwrote:
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 a kind of template mechanism to the server. This is explained on p. 297
in Effective Tcl/Tk Programming by M. Harrison and M. ...
http://.../ticket.json{**title+:+$title} as an example
That's an interesting idea. In principal there's nothing stopping us from
experimenting with multiple approaches, and we can, to a large degree,
implement them side by side until we settle on something we like.
Right now i'm trying to get the easy requests out of the way, and they
have straightforward/non-controversial structures, but eventually questions
like the above will need to be answered before we can start implementing
client apps based on the JSON API.
--
- 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
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/fossil-users
Re: [fossil-users] authentication in JSON: anonymous vs. guest user
On Thu, Sep 15, 2011 at 8:32 AM, fossil-m...@h-rd.org 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 Effective Tcl/Tk Programming by M. Harrison and M. McLennan. Basically the client sends a request giving a template and the data it wants. This allows each client to get fossil data in the format the client needs, with just the data fields it needs. So a client could request just the title of a ticket, or just the contents. Yes, I think t would be a simple way to get a lot of flexibility. 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 complex values, but a field list should be simple to implement and would be a good next step) ___ 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
-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 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).
I'm not sure if LinkType is necessary as it'll presumably be implied
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
parents : {
hash of parent commit : { json : http://..json;, html
: http://...html; },
hash of parent commit : { json : http://..json;, html
: http://...html; }
}
}
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5vFKQACgkQRgz/WHNxCGpczQCeMQa3JMjYxB67BefHXfVPfDUB
dGEAnRBKSR1RX8imx0DpgJNeaDX7TXag
=D42+
-END PGP 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] authentication in JSON: anonymous vs. guest user
On Tue, Sep 13, 2011 at 4:30 AM, Alaric Snell-Pym
ala...@snell-pym.org.uk wrote:
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
parents : {
hash of parent commit : { json : http://..json;, html
: http://...html; },
hash of parent commit : { json : http://..json;, html
: http://...html; }
}
}
If the difference between a JSON and an HTML URL is just the .json (or
.../json/...), then a single URL should be sufficient.
___
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 6:44 PM, Stephan Beal sgb...@googlemail.com wrote: 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 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 The links would be for fetching things not yet retreived, though I will grant it could be possible to construct the link from other information already retreived. Also, I was not suggesting sending links to non-JSON pages, only that a short description might be supplied for the use in displaying an UI. 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). 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 nowiki ... /nowiki (which I mentioned in a post some while back). ___ 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 5:35 PM, Ron Wilson ronw.m...@gmail.com 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 nowiki ... /nowiki (which I mentioned in a post some while back). i've had similar frustrations with not being able to get raw wiki pages, and i'd like the json API to be able to return unparsed pages. This could be used, e.g., to store the pages using arbitrary wiki formats, provided the client has a rendering/parser for the format. -- - 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
-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
ala...@snell-pym.org.uk wrote:
by context, but it might be worth including JSON and human-HTML versions
of each URL, like so:
{
...stufff about a commit...
parents : {
hash of parent commit : { json : http://..json;, html
: http://...html; },
hash of parent commit : { json : http://..json;, html
: http://...html; }
}
}
If the difference between a JSON and an HTML URL is just the .json (or
.../json/...), then a single URL should be sufficient.
That depends if you want to promise forever more that said difference
will hold, and expect clients to do their own regexping to exploit said
promise :-)
ABS
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAk5vyBwACgkQRgz/WHNxCGoBswCgj82M+ZNDR1ZHz2u1vbl5/erR
a9kAl34BkFjg+XaTbczOoOV/UZRk8rI=
=05r8
-END PGP 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] 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] 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] 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] authentication in JSON: anonymous vs. guest user
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 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). Private repositories will need the user to authenticate to get read only access. I trust you're planning to respect the permissions for the anonymous user? Ben -- http://bens.me.uk/ ___ 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
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-ops is not necessarily true. Regards, -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] authentication in JSON: anonymous vs. guest user
On Sun, Sep 11, 2011 at 3:50 PM, Weber, Martin S martin.we...@nist.govwrote: 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 ignoring a range of auth-related details for private and multi-user projects. Tunnel vision on my part. -- - 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] authentication in JSON: anonymous vs. guest user
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, 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. :-? -- - 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
