[Sputnik-list] blueprint

Tue Feb 12 15:46:31 GMT+2 2008

Le 12 févr. 08 à 15:22, Andre Carregal a écrit :

> 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.

No, for me "stack storage" was mean for : "versium over versium"
More on this point later.

Disclaimer : I just started to look at lua/sputnik a few day ago. So I  
can make wrong assumption. I would dive into the code later.

> 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?

Yes, "No need of versium" would have been versium.storage.null
I agree that cost of versioning is cheap.
But a direct mapper of node could be trivial to write  and cover some  
specific case. Look at pre-populated content of sputnik. Some content  
will be over written by user : Home_page.lua. But who would edit  
@Root.lua ?
Root.lua is part of sputnik code. Better is to let it in so it will be  
update with it.
If we get a versium.storage.null pointing sputnik/node_default,  
wiki_data would be keep clean.

But what would happen if user edit Home_page.lua ?
Then came the "stack storage" : user would get a Home_page.lua copy in  
his wiki-data SCM backed versium.storage.svn
What happen here is a copy on write semantic.

You can object it didn't belong to versium to handle this !
But that's possible : making a copy to a new storage is equivalent to  
copying file to a new version. The only difference is that you use a  
storage axis instead of a temporal axis.
Name it : versium.storage.versium

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

What in a programming language isn't a paradigm ?
  - Good one let solve problem with ease.
  - Bad one make you struggle at endorsing complexity in your mind.

> 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.

I agree that complexity need to be balanced :
   - Introduce paradigm, and you get a step learning curve.
   - Always keep idiomatic way and you would suffer as complexity raise

Decoupling storage in sputnik is very good thing, offering some nice  
perspective. So I disagree on "simple, small and flexible"

"simple, small and flexible" pickup two of three :
  Simple and small : do nothing, get nothing.
  Simple and flexible : keep it kiss, do as need, but rewrite it later.
  Small and flexible : use-full paradigms, need to master them.

There is no silver bullet, people always do them in order.

> 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.

I have throw some idea. It isn't that they need to be done. That was a  
test bed to see yours objectives. For my own need I wouldn't do even a  
third of that.

> Maybe it's time to decide if Sputnik should focus on the early game or
> in the late game.

I'm interested in seeing if you foresee post "Earth (0.5)".
I would help immediately on my center of interest (blueprint).

> A third option would be to consider an explicit
> split between a framework and a wiki instance.

Or progressively split part as concepts emerge ?
Post 0.5 goal ?

> 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.

IMHO Zope/Plone is in this case a contriver example.
Zope didn't reach a large audience due a step learning curve.
Plone brings Zope to people by offering a powerful solution.
But dive into Plone is difficult you rapidly head to Zope.

When I use Plone as argument it's simply :
  - It get a good architecture (Five / Zope 3.0 rewrite).
  - All his functionality have been written to cover existing need.

But Plone is doomed by his past :
  - Still based on Zope 2.0
  - Too many functionality
  - Tied to a storage technology

> 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 take a look at sputnik because I see in it : A document / resource  
oriented architecture. Something that exist in Zope, but with too many  
complexity. Immediately Sputnik lack of categorization / meta-data /  
indexing (see a for-coming mail for this point).

For now call it a wiki. Later you can build on it :  blog, cms, GTD  
helper, CRM etc ...
But a wiki has very low requirement on template (one document = one  
page).
So if you need to split, this is the critical point. But it would  
bring a hug complexity.

Just an insight on my personal reflexion :
I don't see Controller / View coupling as a bad thing for user  
interface.
Better push more thing on model, see how you have bring versioning in  
storage.

My feel is that there is a market for a strong document / resource  
back-end that bring representation at URI level (REST ?)
User interaction and data representation can be a fin layer on top of  
it. Empowering a wiki can be a good base for it.
See :
   Delivrance / Plone
   http://www.openplans.org/projects/deliverance/project-home
   Ajatus / CouchDB
   http://www.ajatus.info/

Why Lua ? Not sure need to master it but :
   - Table orientation who fit the objective
   - Small footprint allowing to enable it in web server
       (collapsing network stack)
   - Support of coroutine
       (Need to dive in Kepler, but a single instance of Lua can  
handle multiple request in an event handled fashion ?)

Be care I didn't says that Sputnik must be that dream.
It just what I was fiddling in very long foresight.

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

me too

pierre