-
Notifications
You must be signed in to change notification settings - Fork 168
Road Map
The first phase will be getting the core building blocks in place and having an end-to-end application up and running.
At the end of this phase, SM will be useable (for the brave) and have the necessary extension points to allow users to add features they require.
The components will be extracted from SM2 codebase and cleaned up.
Source repository, build, etc.
Core API that provide the abstractions for SM. No actual implementations.
Stand-alone tag processing library, and rules for converting HTML documents to components that can be used by SM.
Integration for Servlet containers, allowing SM to be used as Filter.
Simple programattic assembly of SM based applications.
This phase will involve a second pass of many of the initial components. From this point on, the work can be done in parallel.
At the end of this phase, it would be worth doing an early release.
Rework the internals of the HTML processor to be more efficient, use less memory/allocation, and take
advantages of newer Java features (such as NIO). Should include a benchmark tool with timings and usage for the processor (compared to previous versions).
Provide foundation for simpler out-of-the-box usage. Provide config mechanisms driven by XML, Java builder interface and convention.
Provide simple facade to get the whole thing running quickly in a web-app.
Allow a page decorators to decorate decorators (recursively). Allows for a clean way to do composition in a website.
Allow decorators to be applied to chunks of content in an existing page.
Basic set of tutorials to get users started.
Downloadable binary and source distributions. Jars in Maven repository.
A complete set of acceptance tests that run in an embedded Servlet container as part of the unit tests.
A suite to verify how well SM works on various Servlet containers. To allow SM to be verified on containers that the development team don’t have easy
access to, the suite should be easy for third-parties to run. Some of this can be pulled across from SM2.
Should include: a deployable web-app, an http based set of tests, a guide to running the suite, a central repository to submit results to, and a dashboard to view the results.
Validate SM on: Tomcat 5.5, Tomcat 6, Jetty 5.1, Jetty 6.1, Resin 3.1, WebSphereAS 7, WebLogic 10
To compliment the micro benchmarks, a performance test suite that tests the end to end performance under heavy load. Should run on all containers and be possible to compare
results across different versions (including SM2).
Get some early feedback. With caveats that it’s still changing.
This phase is to build optional extras to allow SM to play well out-of-the-box with other technologies, with minimal effort by the user.
At this point, the hope is to get a wider community contributing to this. This phase will probably never end ;), but SM can be released frequently whenever it seems appropriate.
Tools to allow SM to be used to build static offline websites.
Tools to build proxy style web-apps, assembling/decorating content from other web servers.
Allow Content instances and fragments to be loaded asynchronously. This is for pages that assemble contents from other sites – it would allow all the requests to happen in parallel and then join at the final render step.
Allow conventions so SM naturally fits in with existing containers.
Spring, Guice, Pico/NanoContainer, Servlet annotations, OSGI
Go!
Keep track of ideas here.
Layer to allow SM2 apps to seamlessly work with SM3. Provide support for old tag libs, config files and DecoratorMappers.
Quick start archetypes for various SM configurations.
Allow decorators and pages to be assembled using inline HTML microformats that are processed by the ContentProcessor, so you don’t have to rely on external technologies such as JSP tags, FreeMarker, etc.