On 15 Sep 2011, at 00:17, Stephan Beal wrote:
As Richard mentioned earlier, the current fossil login mechanism does not
tolerate a given user being logged in multiple times (each new login
invalidates the previous one). While this almost certainly isn't a real
limitation for the HTML
On Thu, Sep 15, 2011 at 6:19 AM, Altu Faltu altufa...@mail.com 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,
On Thu, Sep 15, 2011 at 8:50 AM, Ben Summers b...@fluffy.co.uk 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
On Thu, Sep 15, 2011 at 10:22 AM, Stephan Beal sgb...@googlemail.comwrote:
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
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
On Thu, Sep 15, 2011 at 5:11 AM, Stephan Beal sgb...@googlemail.com 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
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/
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
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 the
On Thu, Sep 15, 2011 at 7:41 AM, Stephan Beal sgb...@googlemail.com 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
On Thu, Sep 15, 2011 at 1:49 PM, Richard Hipp d...@sqlite.org 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
On Thu, Sep 15, 2011 at 3:50 AM, Richard Hipp d...@sqlite.org wrote:
On Thu, Sep 15, 2011 at 5:11 AM, Stephan Beal sgb...@googlemail.comwrote:
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
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
On Thu, Sep 15, 2011 at 2:10 PM, Matt Welland estifo...@gmail.com 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
On Thu, Sep 15, 2011 at 2:18 PM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Sep 15, 2011 at 2:10 PM, Matt Welland estifo...@gmail.com 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
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
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 :
On Thu, Sep 15, 2011 at 8:28 AM, Steve Bennett ste...@workware.net.auwrote:
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
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
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
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
On Thu, Sep 15, 2011 at 2:54 PM, jos van kesteren
josvankeste...@gmail.comwrote:
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,
On Thu, Sep 15, 2011 at 3:12 PM, Joshua Paine jos...@letterblock.comwrote:
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/ http://www.w3.org/TR/html5-diff/
Doh,
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
On Thu, 15 Sep 2011 14:16:23 +0200
Stephan Beal sgb...@googlemail.com 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
On Thu, 15 Sep 2011 14:54:19 +0200
jos van kesteren josvankeste...@gmail.com 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
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),
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),
On Thu, Sep 15, 2011 at 8:54 AM, jos van kesteren
josvankeste...@gmail.comwrote:
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
On Thu, Sep 15, 2011 at 4:34 PM, Richard Hipp d...@sqlite.org 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
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
Oh,
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:
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
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
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
On Thu, Sep 15, 2011 at 6:20 PM, Stephan Beal sgb...@googlemail.com 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
36 matches
Mail list logo
