Robert Ledger wrote: > Stephan Beal wrote: > 1 I am talking about 'extensions' that would always be available but > could be developed independently from the core code if the interface > was already there, such as a parser extension.
IMHO for wiki parsers, perhaps they should be implemented as javascript, and then there could just be a generic feature in fossil for holding a separate repo of javascript (this would also have the advantage that a suite of javascript code for rendering various types of wiki syntaxes would be generally useful outside of fossil, so might attract other people to maintain them, and get more people interested in fossil), and some way in TH1 to interface with javascript, so you could put a hook into the wiki preview button etc. I actually think this has the possibility of making fossil more, not less, clean - instead of having separate "types" for tickets, wiki, and code, which are accessible in different ways from the file system, maybe define a generic facility to have different name spaces of code. Each repo would by default have the "wiki", "ticket", and "code" types as they do now, but instead of the current method of code being checked out by default and having to access other types via commands that dump things to stdout, you could set a default that would be a list of what name spaces you want to check out (non-code name spaces could go to fossil-name spaces/name space-name or something like that). The files in name spaces could be accessed (in addition to any in-web-ui logic as with tickets and wiki) as files, via /name space/tip or something like that. This would also let things like tinymce be added to a fossil repo without making the default repo cluttered. > 2 Fossil is more than an scm, I am considering several applications > for, my own use, based on fossil, where the (it just works, and its > simple) principle is just what I want. I would like to write the extra > application code in such a way that when the fossil core code > is changed, all I need to do us update the core files. If I need to > change core code then it would be difficult to maintain even if I have > only four or five apps. I think that the fact that fossil is a single executable is a *big* selling point; changing to a situation where you need certain additional outside-of-the-repo (.so) files to work properly with certain fossil repos would be a mistake. > Thank you all for your ideas, opinions and links. I am still digesting them! > > I have committed an initial prototype of the creole parser and made > a live version available for testing at. > http://pytrash.co.uk/cgi-bin/CreoleInFossil/ -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark | http://www.fsf.org/about/staff#danny
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
