Hi Stephan, What you propose sounds like the SQLite model where the core is a lib, and the part we SCM users interact with is the CLI (or HTTP). From a user's standpoint, I'd like to assume the project would provide the "default" executable, equivalent to today's fossil executable.
Overall, I have fear that doing it as a lib would take away the "fossilness" of what I'm used to. Maybe that's to say I have some fear of change. But I like Fossil's small size and smallish community. Our community remains receptive and polite. It seems to me that when you publish/maintain an open-source lib, the entire dynamic of your user base changes from people interested in using your app, and how to make best use of it, to hard-core developers trying to build their own product around your lib. Over the past few years, I've noticed the SQLite users mailing list contains a LOT of threads about implementing the lib in bigger projects by people who don't acknowledge there's any documentation. Or the conversations dig deep into C topics like pointers, memory management, and the like. Anyway, I guess my point is, there's a lot less interesting for me there than there once was. And I'd hate for Fossil to go that way. Probably selfish of me. OTOH, from a technical standpoint, it does seem like the right approach. Scripting language: I understand the Tcl roots, and I hope you would consider Javascript as a target. JS seems more universal these days. Maybe the Tcl guys would disagree. I have no idea what that means from an implementation standpoint. I use Fossil as much as a straight ticketing system almost as much as I do as SCM. OK, maybe that's an exaggeration :-) In my company, doing anything through channels takes an act of god. So being able to throw together an ad-hoc issue tracker for a project in a matter of an hour is valuable. So, in the ticketing subsystem, I'd like to see, in no particular order: * built-in persistent integer ticket numbers in addition to the SHA1 ticket/artifact ID. The SHA1 hexdigest fragments are too geeky for management during the weekly status meeting. * persistent ticket create time built-into the ticket record. It's tough to write aging reports without a create time. I know I can add it after the fact. I just don't want to have to. * ticket event notifications, or a table where they're queued for some other process to retrieve/send them. * built-in full text search for tickets. Maybe the new ticketchange schema and JSON API resolve the ticket nums and create time. I'm still struggling with retrofitting the TH1 code for retrieving ticket comments into my existing reports. Otherwise, Fossil as-is fulfills my needs pretty well. Though, admittedly, my needs are relatively small at about 20 active project repos. The projects themselves are relatively small Perl/JS/HTML/CSS apps and the shared code to support them. Thanks for listening to me ramble :-)) -Clark ________________________________ From: Stephan Beal <sgb...@googlemail.com> To: fossil-users <fossil-users@lists.fossil-scm.org> Sent: Sunday, July 21, 2013 3:54 AM Subject: [fossil-users] Random thoughts on Fossil v2 Hi, all, This topic has been tossed around before, but the amount of effort involved in its undertaking has always kept us from actually doing it... To help bootstrap the process of figuring out what Fossil v2 might look like i have started writing down ideas in a public Google Doc: https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view Any of you who have write access to the JSON API docs also have write access to that one, so feel free to expand/comment/etc. It's just a big scratchpad, not a formal doc, nor does it provide any indication of what Fossil's future has in store - it's just ideas regarding what v2 "might" look like if i were to start working on it today (which, in a way, i am ;). If you don't have access to that doc, either send me your gmail address and i'll gladly add you, or post your ideas here and i'll integrate them into the doc. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
