On Wed, Jul 04, 2012 at 10:48:54AM +0200, Ramon Ribó wrote: > I think that it is clear: > > different list -> different data requirements -> different table fields
Well, I understand that different tables can provide more speed and better storage efficiency, but I don't understand what functionality different tables provide, that a single table does not provide. > 2012/7/4 Lluís Batlle i Rossell <[email protected]>: > > On Wed, Jul 04, 2012 at 10:18:10AM +0200, Ramon Ribó wrote: > >> No. I mean that every list would have a different table schema with > >> different fields. > > > > Ah, then I don't understand what would be the advantage of different tables, > > over a single table with all the fields required. > > > > Atentament, > > Lluís. > > > >> 2012/7/4 Lluís Batlle i Rossell <[email protected]>: > >> > 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 <[email protected]>: > >> >> > 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 > >> >> > [email protected] > >> >> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >> >> > > >> >> _______________________________________________ > >> >> fossil-users mailing list > >> >> [email protected] > >> >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >> > _______________________________________________ > >> > fossil-users mailing list > >> > [email protected] > >> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >> _______________________________________________ > >> fossil-users mailing list > >> [email protected] > >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > _______________________________________________ > > fossil-users mailing list > > [email protected] > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
