So I've read the other threads and the uservoices page. There's a
heavy focus on features instead of scenarios, which can be kinda
confusing. Instead of going through those I'll bring some questions
and possible answers/suggestions. My perception of web development may
be kinda rusty, so please let me know where I'm right or wrong.

- MonoRail's mission
  This should be aligned with Castle's mission, which is productivity
while encouraging better design.
  Let's say that MonoRail should encourage a decoupled and reusable
design, with minimal effort to achieve it. The framework takes care of
boilerplate burden and leads you to fall into the pit of success.
Concretely, MonoRail should be about a huge productivity boost without
compromising the quality of the project - e.g. spaghetti code
generation.

- MonoRail's audience
  * Enterprise?
  * Enterprenuers?
  * Small/big shops?
  * Hobbyists?
  In short, I dont know. Any thoughts?

- Value proposition
  Deliver maintainable, valuable solutions in *significant* less time.
Consequentially, shortening the time-to-market

- Competitive landscape
  MS MVC: I can't comment. Anyone cares to share the pros/cons?
Strengthens/weaknesses?
  Fubu: Saw a presentation long time ago. Dont remember much. Same as above.
  Any other? What about other platforms? Which ideas were good and
long-lived, and which weren't?
  What about OSGi and web servers leveraging it in the java space?

- Related Technologies/Standards
  WCF/REST: How do they relate to MR?
  Html5/CSS3: How to take advantage in MR?
  Javascript: How to offer more productivity?

- Goals (not in any particular order)
  Community ecosystem: contributions are encouraged to be packaged and
made available side-by-side, similar to facilities..
  Acceptable Performance, fair trade-off contrasted to other benefits
  Lightweight: Minimal extensible core with predictable behavior.
  Composable: The framework grows or shrink in functionality based on
extensions made available to it. Light-up should be automatic, or with
minimal intervention
  DRY: Should make easier for developers to apply the DRY principle
(no repetition, no duplication)


I think this is enough to start a conversation.


-- 
Cheers,
hammett
http://hammett.castleproject.org/

-- 
You received this message because you are subscribed to the Google Groups 
"Castle Project Development List" 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/castle-project-devel?hl=en.

Reply via email to