I am trying to follow the thread, but the discussion it is getting too
abstract. Everyone is defending concepts but at the end because the
level of abstraction of the discussion everyone may be talking the same.
Architecture, design and layering is fine, as long as you don't lose
focus from the important: ZYpp never got the small community it has
because its design/architecture (libzypp still has bad stuff) or the
language (it is still very advanced C++) but because:
- it got really fast (solved its main showstopper)
- zypper got really good (improved over the competition)
- it got more universal (as it could be used via PackageKit)
So I recommend to focus on what this new module will look like, how fast
it will be, how the command line will look like, the documentation, etc.
From there the language/architecture part is important, but secondary.
Don't forget the architecture depends a lot on the language/ecosystem
you choose, so create it as you envision the end user experience. For
example, if you choose Ruby, the thing you call "lib" which is giving
you understanding headaches in the discussion, may look like a set of
ActiveRecord models, representing nouns, all implementing CRUD and
reusables across UI, cmdline and web controllers. But in Python it may
look completely different.
Then do it!. Then refactor. If you got the experience you aimed for, do
a second module, refactor the infrastructure to reflect the new use
cases, and iterate.
Just my 0.02€.
--
Duncan Mac-Vicar P. - Novell® Making IT Work As One™
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
