On Tue, Apr 3, 2012 at 2:27 AM, BohwaZ <[email protected]> wrote: > I would be happy to see them somewhere I can actually read them. I > often program on my laptop, using a slow 3G connection, and Google Docs > is an incredible pain to use, it never works (sometimes the IP address > is blocked, sometimes the javascript doesn't load, sometimes the > website doesn't load...). >
Good point - on my netbook it's a bit painful as well. TENTATIVELY: http://fossil.wanderinghorse.net/wikis/fossil-json/ i've been tinkering with a port to a fossil wiki there, but i am not yet committed to this approach (mostly just experimenting with the structure and page naming conventions). If i end up sticking with this approach, the page list (as it appears above) will be created by hand so that it doesn't include every single page (just the top-level pages). I'd really prefer a static wiki as I don't enable javascript as long as > it's possible (it's slow), and I always need to have my programming > references at hand, where they can load very fast to not interrupt my > work. > i can't promise to provide statically-generated copies. (A) i wouldn't use them myself, so the maintenance involved would be 100% time sink for me, (B) the nature of a JSON API excludes any clients which cannot process JSON (e.g. static web pages), so i don't feel compelled to make any extra effort for such clients. So whatever you plan to use to edit the doc (personally I hate all > those wiki syntaxes, and markdown is even worse), please keep a > standard static html copy online. > i also don't like wikis, but the convenience of being able to document on the go is just too tempting to give up. i sympathize with the position about static pages, but see above. The wiki site currently runs very well on my android phone (need to dig my 3DS out of the cellar and try it out), and the majority of major web sites nowadays require JS, so i don't feel bad about excluding static clients. I think that the best option would be to integrate some basics into > fossil itself so that you can do: > > $ fossil help json wiki get > The main problem with that is that the 'fossil help' text is auto-generated from special tags in the C code for the commands/pages, and those tags are used by the help _and_ dispatching back-ends to channel a given command to the appropriate C function. The JSON code does not use those tags because i needed customized command dispatching in order to consolidate the HTML and CLI modes into a single interface (fossil normally has different routines for the CLI/HTML versions of any given command, but the JSON API has only very minor differences between CLI and HTTP modes). That simply means i can't tie in to fossil's built-in mechanism for help. i have considered adding such a feature to the JSON API, and even experimented with it, but (A) the help results would have to be in JSON form (making them quite unreadable from the command line) and (B) the API changes all the time, so maintaining the help text would be a PITA at this point. i am still, however, considering a /json/help/COMMAND function which returns help text for any given command (but how to store such text internally is still up in the air, e.g. as constant C strings or in the db?). BTW thanks for the JSON API that I now use for my projects to have a > simple public website which fetches a default home wiki page :) > Great :). Send us a link - i'd be interested in seeing how people (or person ;) are (is) using it. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
