[Sputnik-list] proposed versium modifications

[Yuri Takhteyev]

> > 2. The "extra" field in versium and the storage implementations will be dropped.
>
>  So, did you come to the conclusion that is not worth to keep this field?

Well, I am asking for your thoughts, but mine is that it hasn't served
any purpose so far, so maybe it's best to just get rid of it until we
are certain that we need it.  The problem with the "extra" field is
that once you start using it, your code will no longer work across all
versium implementations.  And if you are going to be writing code that
is specific to an implementation, then why not use the corresponding
API directly...

>  Are you planning to release 0.3 beta-X with the new Versium?

0.3-beta branch is history.  We are on version 8.02.x now!

I am also no longer doing big releases.  Instead, the idea is to
release a new version of each rock individually when there are enough
features to warrant the work that it takes to make a rock.

See http://sputnik.freewisdom.org/en/Releases  (note that you can
subscribe to the RSS feed for this page if you want).

The reason for this change is that with LuaRocks the overhead of
making a release or upgrading is reduced substantially.  In case of
versium-svn, my plan is that I will release it as a separate rock that
will work with sputnik and versium rocks that have been released
earlier.  So, this won't require a new sputnik release.  Once I make
the changes to versium that we've been talking about, I will make a
set of rocks (sputnik, versium,
the-new-thing-that-is-on-top-of-versium, and versium-svn) and release
those all at once.  When?  As soon as I commit the changes and figure
out how to make rocks more efficiently.  (Hisham didn't like my old
rocks, but let's see if he likes those generated with petrodoc.)

>  About speed, I noticed Sputnik was calling some functions/methods
>  more than once for the same file when loading a page, maybe would
>  be good to see which calls could be avoided. Is there some connection
>  between this and "get_modification_time"?

This could be because each request requires that at least nine nodes
are fetched from versium (the node that is being requested plus @Root,
_config, _templates, _translations, _yui_reset, _colors, _layout,
_navigation).  The solution to this would be to cache them, for which
get_modification_time will be needed.  When this method is available,
it would be possible to just ask versium if those nodes got modified,
and if they haven't, then either use their copy in memory or even just
return to the user cached HTML.  (Perhaps even compressed?)

- yuri

-- 
http://sputnik.freewisdom.org/