I don't have any problems with changing the design, but I just think that the content is more important than the color
On Wed, Jun 29, 2011 at 07:39, Lars Heinemann <lh...@apache.org> wrote: > Regarding the webpage design... > > As already stated I don't like the design of the webpage. It seems to be a > duplicate of the Karaf homepage > and I can't see that the page is now more easy and clean as we once intended > to do. Well, if I can slightly object, it's kinda the opposite, as Karaf has simply reused the ServiceMix design ;-) > I'd like to point you to the following design proposals which I think are > really awesome looking... > > http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine) > http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch) > > Shouldn't we go for something like this? Those designs are awesome looking > and have a very clear and simple navigation concept. Both looks really good to me, but before switching the css, we need to get the scalate stuff to work and the content up to date, so that we can switch to that new stuff asap. Then, we can propose changes on the pure css stuff (colors, images, icons etc...) based on the new website. Once we have the infrastructure in place, we can easily branch or experiment with css patches. > Wdyt? > > Best regards, > Lars > > -------------------------------------- > > Lars Heinemann > FuseSource > Email: lh...@fusesource.com > Web: http://www.fusesource.com > Blog: http://lhein.blogspot.com > Twitter: lhein77 > > > > Am 29.06.2011 um 01:39 schrieb Gert Vanthienen: > >> Guillaume, >> >> >> All this seems to make a lot of sense to me - let's drop the bits that >> don't bring any value (any more) and try to add value to the project >> by focusing on providing these container-level services to integration >> projects. I also like the idea for creating both a Tomcat and a Karaf >> based distribution. That way, people can start with the more familiar >> WAR deployment in a simple Tomcat container and, as they need the more >> advanced features, gently migrate to the full OSGi-goodness of the >> Karaf based distribution. >> >> For the website, I took an initial stab at migrating the relevant bits >> of existing website contents to a Scalate/Maven-based project at >> https://svn.apache.org/repos/asf/servicemix/website and pushed an >> initial copy of the result out to >> http://servicemix.apache.org/staging/ so we can start adding content >> again there until we're happy enough with the result to promote this >> to become the home page. >> >> Information about the current location/build/... of the documentation >> project can be found at >> http://servicemix.apache.org/documentation-project.html - we have a >> bit of content for ServiceMix 4.x in there already but it still needs >> quite some work. For ServiceMix 5.x, we should probably grow the >> habit of documenting every single feature the moment we add it to the >> codebase right from the start so we can build the documentation right >> along with the actual code. >> >> >> Regards, >> >> Gert Vanthienen >> ------------------------ >> FuseSource >> Web: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> >> >> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet <gno...@gmail.com> wrote: >>> Last week, I've been discussing with a few committers about the >>> ServiceMix roadmap. >>> So I'd like to communicate those thoughts to a wider audience. >>> >>> We've been discussing already that the value of ServiceMix (which was >>> the JBI layer in ServiceMix 3 >>> and the container side in ServiceMix 4) has moved mostly to Camel and >>> Karaf respectively. The remainining >>> bits are mostly the NMR. However, the value of the NMR is not in the >>> NMR itself, but rather the NMR was >>> supposed to enable various container-level features. However, we >>> haven't really built those features so >>> that the *real* value of the NMR is not that high currently. >>> >>> So, what we've been discussing is to focus on that added value in a >>> more transparent way by tweaking >>> Camel a bit to support global interceptors, so that one could deploy >>> the real routes without having to >>> force the use of a specific transport such as the current NMR. This >>> way, a user could test / develop >>> the Camel routes or take existing Camel routes and deploy them in >>> ServiceMix, thereby transparently >>> enabling a bunch of useful features. We've been thinking about adding >>> message tracing / timing / auditing, >>> sending test messages, security checks, viewing flows, persistent >>> modification of camel >>> routes, camel route versioning, etc... That need to be coupled with a >>> web console similar to the >>> Camel / ActiveMQ web consoles, to actually display all the data to >>> provide useful information for monitoring >>> Camel routes and help diagnosing problems in production for example. >>> There's really nothing magically new >>> here and some of those features were actually part of ServiceMix 3, >>> but without much focus on those and >>> they have always kept a bit on the side. The idea is really to make >>> ServiceMix the best possible container >>> for deploying Camel based integration. >>> >>> Additional things that could be pushed inside ServiceMix 5 would be a >>> Tomcat based container deployment >>> option (for those that don't need OSGi), a new manual similar to what >>> we have in Karaf (maybe reusing >>> parts of it). We'd also need a new website (without the technical >>> doc, as we have for Karaf I think). >>> >>> On the maintenance of the JBI components and NMR/JBI layer, I think we >>> should keep them in smx4. >>> People wanting to deploy those could easily add a pointer to the >>> servicemix 4 features descriptors and >>> deploy the needed features. So we could officially deprecate those >>> and tell users they won't be >>> available in smx5. This also means that there's really not much to >>> reuse from smx4, so smx5 would >>> have its own new and dedicated svn area. >>> >>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the >>> coming months, so those are not >>> faithful wishes, but really something I want to start implementing asap. >>> >>> Feedback welcomed! >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
