Tinkering with some ideas/thoughts on the shadow-like system I want to put together…here is what I had jotted down in a text doc:
Core - very simple (spring bean factory-like)
Modules - Totally Pluggable. Self-Installing/Uninstalling/Updating.
- plugin 3rd party (wordpress) modules (and hence the services
provided by them…as well as 3rd party
core-like modules (persistence? security).
Module categories?
No programming language requirement for modules?
Services (modules can publish services)
Event Pub/Sub - can subscribe to an recieve messages
Simple to configure/layout/understand
Support for workflows
Portal features
View Template features
View Theme features
Versioning Features/system
Ease of Module interaction
i18n
Scale up/down
pluggable security w/declarative and programmatic support
Self-Documenting (meta?)
Good Defaults (runs out of box).
Web-Based installer (wizard-like) runs on simple core with simple web install module
Stand-Alone installer (with own internal web server)
Easy to test (test-harness module?)
Extreme Focus on Core for R1
- IoC Container
- configured via properties files or xml files
- module manager
- install/update/remove/query modules
Install:
d/l zip (tar.gz)
unpack
modify install.config (db info)
open browser to /install
(at this point, the config has been verified/validated and the module manager has
been installed & self-updated)
choose install mode (minimal, bundled, custom, all) & whether new versions
should be installed if found
(if bundled) ask for purpose of site (blog, community portal, ecommerce)
(if custom)choose modules to install (possibly also have indicators for which
modules are part of which bundles)
For modules to be installed, choose defaults/manual config options for each/all
configure modules (if chosen to).
On Versioning.
Modules are versioned. At the point a module is being upgraded, the resident
data for the module will be modified (if necessary) to conform to changes required
in the version.
Data may or may not be versioned as well (module and data specific).
Data associated with a module (whether or not the data itself is
versioned) should know what version of the module its current state is set for
(column in table? flag exported data? point of export.)
Modules can express dependencies on other modules including version (”after”,
“before”, “only”).
Modules can indicate they provide a common service and the version of the
service that they adhere to and the completeness of the implementation
(what operations are/are not supported).
can versioning be totally aop-like?
create module (document maker)
defines tables (w/o version stuff)
installs module.
enables versioning for the module
tables are modified (renamed & version columns created & then views?) to have
version info. Modules should provide a dao to ‘blindly’ map from a rs (or map)
to the value object (or subclasses thereof)…or just provide it in a mapping
(like ibatis?):
name = DOC_NAME
desc = DOC_DESC
Should versioning support need to be coded into the modules…maybe.
modules would have a versioning config of some sort to indicate what
operations support versioning.
Would be nice if other interfaces could interact with system (e.g. a
remote swing admin console)…perhaps just via exposing some services
and method over web service. brings up some security questions.
Indexing/Search as a core feature
- modules should provide a mechanism for accessing the data that they
store (for external indexing)…along with a mechanism by which that
data can be re-accessed.
