[Sputnik-list] blueprint

[Andre Carregal]

On Feb 12, 2008 8:35 AM, Yuri Takhteyev <yuri at sims.berkeley.edu> wrote:
> >  An other usage would be to stack storage :
> >    - install storage for : special page, base template (No need of
> >  versium)
> >    - skin storage for customs templates (would use versium in
> >  development phase)
> >    - base storage for : user configuration and document
> >      - alternate storage for test, staging edition. May be mapped to
> >  SCM branching.
>
> Very interesting, though you are confusing "versium" (the API) with
> "versium.storage.simple" (a file-based implementation).  But I see
> what you mean.
>
> André, what do you think about this?

I'm not sure I got the point correctly, but while I agree that
different resources may need different storage policies, using
different APIs for that would be confusing.

If you are talking about using a common API (versium) but separate
storage models for the resources then it may be a reasonable idea. On
the other hand, if one of the layers uses versioning, then why not use
it for every resource?

The way I see it, Sputnik is a curious case of "paradigm overload"... :o)

While it tries to offer Pareto balances on different areas (storage,
information architecture and retrievability for example), it also
tries to keep things simple, small and flexible. I guess this is not
doable in the long run, since you have to compromise somewhere.

Sputnik started as a really simple/flexible wiki engine and has
evolved into a very powerfull wiki framework, I just can't see it as
simple anymore. Not that this is bad news per se, it's just a matter
of having the driving keywords clear during the design.

Maybe it's time to decide if Sputnik should focus on the early game or
in the late game. A third option would be to consider an explicit
split between a framework and a wiki instance.

Thus one layer would have real power while the other would customize
this power in order to be reachable by the masses. While way more
advanced, Zope/Plone are one example of this approach. One is a
generic content biased web framework, while the second focus on
solving the CMS case.

In our case, one layer could offer the basic tools (versioning,
templating, search, categorization, user management, plugins etc)
while another layer could be comprised of applications that use those
tools (be it a wiki, blog, cms, GTD helper, CRM etc).

I hope this has not been too noisy. :o)

André