No. I mean that every list would have a different table schema with different fields.
RR 2012/7/4 Lluís Batlle i Rossell <vi...@viric.name>: > On Wed, Jul 04, 2012 at 10:00:52AM +0200, Ramon Ribó wrote: >> An interesting new capability for fossil could be the following: >> >> That it allowed to have more than one tickets list, with different >> tables and reports in every list. This could have several advantages: >> >> 1- Keep a completely separated list for bugs and for new features, for >> example >> >> 2- Use fossil as a tool or library for other apps in order to access a >> dabatase with tables with full history and with easy syncronization. >> This is something that sqlite does not offer by itself > > I think this can be achieved simply allowing multiple "new ticket" pages, > instead of only one. Different new ticket pages could set a table field to > specific values, and then multiple reports could filter one or another. > > Regards, > Lluís. > >> 2012/7/3 Stephan Beal <sgb...@googlemail.com>: >> > Hi, all! >> > >> > About 5 minutes ago i got home from the all-day meeting with list members >> > Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in >> > Germany and 3 of us 4 carry American passports), and now i've got a small >> > hill of notes scribbled on the back of business cards and yellow sticky >> > notes... >> > >> > Wow, what a day. >> > >> > We didn't actually get around to hacking. Rather, we had an 11-hour series >> > of discussions, starting off with an introduction to Fossil (for the >> > benefit >> > of colleagues of mine who dropped in and as a practice run for DRH's >> > presentation this coming Sunday at a TCL conference). We discussed areas >> > for >> > improvement and came up with some cool new TODOs, none of which either he >> > or >> > i will get a chance to work on anytime soon :/. >> > >> > Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: >> > please ammend if i have left something out): >> > >> > - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. >> > We looked closely at this and it this will not be nearly as much work as i >> > first anticipated, but we will have to munge the output just a tiny bit to >> > suit or needs. >> > >> > - Adding more metadata to wikis, e.g. a title field. We might embed this >> > into the wiki content using a new wiki tag or similar. We will have to >> > enable the "style" attribute on tags in the wiki content (style is >> > currently >> > filtered out by the wiki out of safety concerns), and if anyone can name a >> > concrete security reason why that would be a Bad Idea, please speak up! >> > >> > - We might (might!) use jQuery simplify the client-side implementations. >> > This would include a new config option which specifies whether an embedded >> > copy of jquery should be served or a copy from e.g. a Google CDN (offline >> > usage requires an embedded copy). >> > >> > - Adding a system for integrating "custom pages" to fossil repos, e.g. >> > /myCustomPage, which would call content stored in the db. The original idea >> > was to use this as a new layout mechanism for the site, but we think that >> > this could possibly be used to reimplement some of the current "static" >> > pages . Part of this would include a templating mechanism. The pages could >> > have security restrictions and could be flagged as syncable/clonable (or >> > not) by the site admin (only admin users would be able to create/edit such >> > pages). A logical extension of this would be to build up snippets/widgets >> > which users can use to customize their pages (e.g. embedding a >> > mini-timeline >> > overview in their home page). >> > >> > - The JSON API already provides a good deal of what some of the above would >> > need, and it might become activated by default. Before this happens, a full >> > audit of the code is necessary, as well as stress tests to check for memory >> > mishandling and whatnot (a "fuzzer" test - i learned a new word today). >> > >> > - "External repositories" (a-la SVN or git modules) came up once or twice, >> > but we didn't actually discuss adding it to fossil. i'd like to throw it >> > out >> > there as a potential TODO, though. In short, this allows one to "embed" >> > external repos as subdirs of one's own repo, and is normally used to pull >> > in >> > 3rd-party code upon which an app depends. A local pull would also pull >> > x-repos, but they would not participate in push (that might be the next >> > step, of course). >> > >> > - Fossil timeline graph in CLI mode (like git). Several other git-like >> > features came up but i do not recall what they were :/. (@self: remember to >> > put DRH in touch with your libgit2 contact.) >> > >> > In the 11 hours we discussed a great deal, and there was certainly more >> > that >> > i missed altogether or didn't manage to jot down, and i would ask the other >> > attendees to extend the above if i've left anything interesting out. >> > >> > @non-attendees: i intentionally left some of the above quite vague to try >> > to >> > spark your imaginations. Some of the topics we discussed in some detail, >> > including potential implementation strategies, but rather than describe >> > that >> > i'd like to hear what ideas others can derive from the descriptions above. >> > >> > i unfortunately failed to take any pictures except one of the whiteboard. >> > :/ >> > >> > We would love to hear your thoughts/elaborations on the above ideas. >> > >> > Happy Hacking! >> > >> > PS: Please pardon my brevity and typing mistakes - i'm on a tablet. >> > >> > >> > _______________________________________________ >> > 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 > _______________________________________________ > 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
