Hey Pau, 2009/11/4 Pau Garcia i Quiles <[email protected]>: > Great news! > > Will you include the blog webapp as an example, or as a separate > download in the future?
The blog will be an example of how a Wt application should use a Wt::Dbo database model. We currently plan to distribute Wt::Dbo together with Wt, but it will be a library that can be used independent of Wt. > Regarding the Debian packaging, do you have a release plan for the > future? I. e. is it "new versions of Wt will be released every 3 > months", or "new versions of Wt will be released when we feel we have > something valuable, be it next week or in 6 months". Not that I care > about numbers (3.0, 3.1, 3.2.87, etc) but about binary compatibility: > Wt usually breaks binary compatibility with each release, which makes > it quite unfit for packaging as a shared library (and I really dislike > libraries packaged as static libraries). We do not have a clear plan other than we always want releases to closely track stable features. In the past we have been able to release on average every 2 months, and that feels about right. Does Debian packaging work better if we have a more strict release plan ? W.r.t. binary compatibility: this will require a switch within the code to adopt a style similar to Qt: a strict separation of interface and implementation classes using the pimpl idiom. I think at this point we are not ready to invest a lot of effort there. Given that we tend to break binary compatibility with every release, our personal experience is that on a real server system, static linking is really helpful, as it allows you to have e.g. an experimental version of the application (against a new version of the library) running next to older versions of the same applications or other applications, each linked against their own version of Wt. Personally, unless static linking has all kinds 2nd degree problems I am unaware of, I would really think it is a plus to include static libraries in a binary package. > My code is available at gitorious ( > http://gitorious.org/wtdesktop/wtdesktop ). Will you hack publicly (i. > e. at gitorious or in the public master branch at webtoolkit.eu), or > will you do further development in private? If you'd ratherhack in > your private repo, then suprise us with something awesome, it's OK by > me, but please tell me now. My spare time is very scarce and I'd hate > to use it to develop something for Wt, then find you were doing the > same thing, or it won't be useful because of some changes in Wt. For sure, we will discuss how we do what, once we figured out what to do! Obviously, I really like the project and I think it is easy to delineate a feature set that is useful enough and does not require too much work. Perhaps it is a delicious occasion to use wtdesktopius to get some experience with gitorious. > The latest code at gitorious tried to implement automatic port > selection (by requesting a new http server on port 0, as Wim > suggested) but it does not work. Due to the async'ness of Qt, the > WebKit browser starts before the WServer is availaable, therefore I > had to use signals and slots Unfortunately, I was unable to get Boost > signals and slots communicate with Qt signals and slots, and I've been > very busy since then. The error might be obvious. I hope to be able to contribute to the bootstrapping situation ... Regards, koen ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
