On 4/4/06, Max Ischenko <[EMAIL PROTECTED]> wrote: > > On one hand, having FastData separatedly is appealing: separate release > cycle, better modularity and other bonuses mentioned. > > But there is extra work needed to make this happen. So, unless there is > a person to maintain/improve fastdata, it's may be easier to keep it > the way it is.
I'm not sure that there's really extra work required (beyond the work that I just did and will check in shortly). The main bit of extra work is when it comes to release time. > Being one of those who complain about fastdata limitiation, I think it > is really "very" alpha and leaves a lot to be improved before it can be > considered usable. Yep. My thought exactly. I think there's a lot of potential and many cool things we can do there, but I'd rather not push it as a core feature of TurboGears until it's really ready. Better to delight the users with something really cool than to annoy them with something that's possibly better than nothing but still half-baked. > Removing it from the core might have another benefit: it won't be in > 0.9/1.0 release and hence will have lesser obligations on > backward-compatibility. Indeed. Those watching the commit messages will see that I've already created a separate project out of FastData. In a little bit, I'll commit the change to turbogears itself that removes it from the core package. (It will still be available at turbogears.fastdata, though.) Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
