Re: [fossil-users] JSON/wiki: what info needs to be returned for...

On Thu, Sep 15, 2011 at 6:20 PM, Stephan Beal wrote: > For /json/wiki/list requests, what page info needs to be returned? > i was thinking: > name, sizeInBytes (as opposed to size in UTF8 chars), name of last > committer, artifact ID > i'm not sure i can get the committers name easily, but the res

Re: [fossil-users] authentication in JSON: anonymous vs. guest user

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 "

Re: [fossil-users] JSON login demo: is this interface acceptable?

On Wed, Sep 14, 2011 at 6:40 PM, Stephan Beal wrote: > Hi, all! > Just implemented... > Request: > GET: /json/login?n=name&p=pass > Param names "n" and "p" are for compatibility with the current usage, and > may optionally be written out as "name" and "password". > or POST: /json/login > POST requ

[fossil-users] JSON/wiki: what info needs to be returned for...

Hi, all! Now that logging in works, i'd like to start tackling some of the bigger fish... For /json/wiki/list requests, what page info needs to be returned? i was thinking: name, sizeInBytes (as opposed to size in UTF8 chars), name of last committer, artifact ID i'm not sure i can get the comm

Re: [fossil-users] fossil: numerous open trunk leaves

> How'd that happen? Can/Should the open leaves 2-6 be closed? Speaking of cleanup, what about removing the following files from trunk? kktodo.wiki rse-notes.txt ci_cvs.txt ci_fossil.txt cvs2fossil.txt -- Dmitry Chestnykh ___ fossil-users mailing list

[fossil-users] fossil: numerous open trunk leaves

Hey fellow archaeologists, I was just wondering: how did fossil end up with all these distinct open leaves of the same branch? If you look at our leaves display here: http://fossil-scm.org/index.html/leaves And do a search for "tags: trunk", you should find six instances of trunk leaves: ht

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On 09/15/2011 05:34 PM, Richard Hipp wrote: > > Using the "birthday paradox", I calculated last year that for the > SQLite repository, if it continues to change and evolve at the same > rate it has for the previous 10 years, will encounter its first SHA1 > collision in approximately 3.6e20 years

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On Thu, Sep 15, 2011 at 4:34 PM, Richard Hipp wrote: > On Thu, Sep 15, 2011 at 8:54 AM, jos van kesteren < > josvankeste...@gmail.com> wrote: > >> Dear fellow fossil-users ? >> not just improbable, but very very very improbable. > > > ...repository database file will have grown to about 5e28 byte

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On Thu, Sep 15, 2011 at 8:54 AM, jos van kesteren wrote: > Dear fellow fossil-users ? > > As we all know, SHA1 and its successor algorithms are specifically > designed to make collisions > not just improbable, but very very very improbable. > Using the "birthday paradox", I calculated last year t

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On Sep 15, 2011, at 2:54 PM, jos van kesteren wrote: > > Just for the sake of my curiosity; > is there any fossil user out there who has encountered a SHA1 collision ? Nope. You'd hear about it in the news :-) There's a theoretical collision attack at 2^51 operations (instead of the ideal 2^80)

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On Sep 15, 2011, at 2:54 PM, jos van kesteren wrote: > > Just for the sake of my curiosity; > is there any fossil user out there who has encountered a SHA1 collision ? Nope. You'd hear about it in the news :-) There's a theoretical collision attack at 2^51 operations (instead of the ideal 2^80)

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On Thu, 15 Sep 2011 14:54:19 +0200 jos van kesteren wrote: > As we all know, SHA1 and its successor algorithms are specifically > designed to make collisions > not just improbable, but very very very improbable. > > However, there are a lot of fossil users doing lots and lots of > commits and ot

Re: [fossil-users] conflict between HTML5 and Fossil

On Thu, 15 Sep 2011 14:16:23 +0200 Stephan Beal wrote: > And now something which has nothing to do with JSON... > > i noticed yesterday (via a comment in one of the tickets) that fossil > now sends an HTML5 doctype. That's all fine and good, but the wiki > does not actually play well as-is with

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/fossi

Re: [fossil-users] conflict between HTML5 and Fossil

On Thu, Sep 15, 2011 at 3:12 PM, Joshua Paine wrote: > "The target attribute for the a and area elements is no longer deprecated, > as it is useful in Web applications, e.g. in conjunction with iframe." < > http://www.w3.org/TR/html5-**diff/ > > Doh, that means i

Re: [fossil-users] Has any fossil user ever experienced a SHA1 collision?

On Thu, Sep 15, 2011 at 2:54 PM, jos van kesteren wrote: > Just for the sake of my curiosity; > is there any fossil user out there who has encountered a SHA1 collision ? > Almost 4 years with fossil (nearly every day) and never noticed a collision. According to wikipedia, there has never been a

Re: [fossil-users] conflict between HTML5 and Fossil

On 9/15/2011 8:16 AM, Stephan Beal wrote: (Granted, i don't honestly believe that any existing browsers will remove the TT tag or the A.TARGET attribute, but they are officially deprecated.) "The target attribute for the a and area elements is no longer deprecated, as it is useful in Web appli

[fossil-users] Has any fossil user ever experienced a SHA1 collision?

Dear fellow fossil-users ? As we all know, SHA1 and its successor algorithms are specifically designed to make collisions not just improbable, but very very very improbable. However, there are a lot of fossil users doing lots and lots of commits and other stuff that involves lots and lots of SHA1

Re: [fossil-users] authentication in JSON: anonymous vs. guest user

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

Re: [fossil-users] Fossil tutorial - Oct 25 in Manassas VA

On Thu, Sep 15, 2011 at 8:28 AM, Steve Bennett wrote: > On 15/09/2011, at 1:42 AM, Richard Hipp wrote: > > I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct > 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk > conference. See http://www.tcl.tk/community/t

Re: [fossil-users] authentication in JSON: anonymous vs. guest user

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" :

Re: [fossil-users] Fossil tutorial - Oct 25 in Manassas VA

On 15/09/2011, at 1:42 AM, Richard Hipp wrote: > I'm schedule to give a 3.5 hour in-depth tutorial on Fossil on Tuesday, Oct > 25 from 09:00 to 12:30 in Manassas VA as part of the 2011 Tcl/Tk conference. > See http://www.tcl.tk/community/tcl2011/schedule.html for schedule and > registration in

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

On Thu, Sep 15, 2011 at 2:18 PM, Stephan Beal wrote: > On Thu, Sep 15, 2011 at 2:10 PM, Matt Welland wrote: > >> ...checking in of controlled files from the web interface? It imagine it >> would require >> > > Just FYI: one of the goals of the JSON API is saving wiki pages (and > Sorry, hit sen

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

On Thu, Sep 15, 2011 at 2:10 PM, Matt Welland wrote: > In my own projects I've found this to be true also but then we sorely miss > the ability to make quick edits which is one of the best things about the > Wiki. Is it technically feasible to implement editing and checking in of > controlled fil

[fossil-users] conflict between HTML5 and Fossil

Hi, all, And now something which has nothing to do with JSON... i noticed yesterday (via a comment in one of the tickets) that fossil now sends an HTML5 doctype. That's all fine and good, but the wiki does not actually play well as-is with HTML5. In v5 several features wiki authors rely on are de

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

On Thu, Sep 15, 2011 at 3:50 AM, Richard Hipp wrote: > > > On Thu, Sep 15, 2011 at 5:11 AM, Stephan Beal wrote: > >> Hi, all, >> >> When adding new docs (for the up-coming json bits), which is the currently >> preferred approach: wiki or embedded docs ? >> > > I've grown to prefer embedded docs,

Re: [fossil-users] any objections to moving my JSON branch into the main repo?

On Thu, Sep 15, 2011 at 1:49 PM, Richard Hipp wrote: > No objections. > Thank you very much :) http://www.fossil-scm.org/index.html/timeline?r=json @Contributors: that branch is in no way holy. Feel free to hack. See src/json.c for details. Most of the interesting higher-level bits are in func

Re: [fossil-users] any objections to moving my JSON branch into the main repo?

On Thu, Sep 15, 2011 at 7:41 AM, Stephan Beal wrote: > Yo! > > Currently the JSON code is in my own fossil copy, which i regularly > merge/resolve against the trunk. Now that the code is moving along nicely, > would anyone object to me moving it into the 'json' branch of the main repo? > No obje

Re: [fossil-users] lol: funny favicon behaviour in local server mode...

On Sep 15, 2011, at 1:44 PM, Stephan Beal wrote: > Last night i ran a media player (VLC) web service on localhost:8080. Today > when i started 'fossil ui' my browser had cached the favicon.ico from the > media player and now shows the VLC favicon in place of fossil's. > > (Not a fossil bug, by t

[fossil-users] lol: funny favicon behaviour in local server mode...

Last night i ran a media player (VLC) web service on localhost:8080. Today when i started 'fossil ui' my browser had cached the favicon.ico from the media player and now shows the VLC favicon in place of fossil's. (Not a fossil bug, by the way.) -- - stephan beal http://wanderinghorse.net/ho

[fossil-users] any objections to moving my JSON branch into the main repo?

Yo! Currently the JSON code is in my own fossil copy, which i regularly merge/resolve against the trunk. Now that the code is moving along nicely, would anyone object to me moving it into the 'json' branch of the main repo? -- - stephan beal http://wanderinghorse.net/home/stephan/ __

Re: [fossil-users] new fossil docs: is the wiki or embedded docs preferred?

On Thu, Sep 15, 2011 at 5:11 AM, Stephan Beal wrote: > Hi, all, > > When adding new docs (for the up-coming json bits), which is the currently > preferred approach: wiki or embedded docs ? > I've grown to prefer embedded docs, since they are tied to specific versions of the code, and hence you k

[fossil-users] new fossil docs: is the wiki or embedded docs preferred?

Hi, all, When adding new docs (for the up-coming json bits), which is the currently preferred approach: wiki or embedded docs ? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.or

Re: [fossil-users] JSON login demo: is this interface acceptable?

On Thu, Sep 15, 2011 at 12:40 AM, Stephan Beal wrote: > i haven't yet done anonymous user support (that requires special handling > because of the random password). Nor have i yet thoroughly tested THIS > support (it's literally under 10 minutes old). "Seems to work." > BTW: this seems to mesh fi

Re: [fossil-users] same user, multiple logins: the problem and a potential solution

On Thu, Sep 15, 2011 at 10:22 AM, Stephan Beal wrote: > > >> Advantages are that no state is stored in the database and multiple logins >> are possible, with simpler code.[2] You can invalidate all logins by >> changing the secret key, but can't invalidate individual sessions. >> > > But that woul

Re: [fossil-users] same user, multiple logins: the problem and a potential solution

On Thu, Sep 15, 2011 at 8:50 AM, Ben Summers wrote: > For example, you could form the string > > stephan:192.168.0 > > then sign it with the secret key, and get > > stephan:192.168.0:38fa112673be4946702a74d1d0d1c0b6bd9f0162 > That is in essence what Richard has done already. He uses the firs

Re: [fossil-users] same user, multiple logins: the problem and a potential solution

On Thu, Sep 15, 2011 at 6:19 AM, Altu Faltu wrote: > It would be simple to have one auth token for each login and purge stale > auth tokens regularly. Purging stale tokens should be a matter of few SQLs > for the current backend of fossil, sqlite. > In principal it's simple, yes, but the current