> Hi Gongo,
> Hi Daniel,
> Thank you both for your insight. I welcome these types of healthy
> discussions. Here are my ideas.
> First off, I feel we do need a major rewrite of Tiki. Similar to the
> successful DB abstraction overhaul (thanks to Redflo and mose), I feel
> we need:
> 1-to enhance our template/theme system. Smarty is great but we need to
> make it easier to customize themes. (musus is working on a proposal)
> 2-a major overhaul of our permission system. We need Gustavo Muslera's
> WYSIWYCA, category-based permissions and better user/group management.
maybe not category based permissions, but plain old object permissions!
You can access only that document and nothing more in that container
in contrast to 'only that container is accessible by you, including all
that is in it'
> About Tiki core vs modules, bloat, Tiki being monolithic, etc Coming
> from the Postnuke world, I understand the potential and the power of a
> decentralized team and app with a core & API. However, this also has its
> drawbacks. You'll have several modules doing about the same thing. I'd
> prefer several people work together to produce one nice module/feature.
> Having all our team working directly in the CVS has worked very well for
> us so far. When someone finds a bug in a theme, he'll correct in all of
> them. In Postnuke, this would not happen.
About the 'several modules doing the same thing'. This can be a good
thing as well. You can choose which one to use (app menu's in current
tiki for instance), and choice is usually good ;-). Actually, there is
a lot of code replicated right now. Every entry point practically does
this to some extent. (tiki-xy_z.php files)
Modularising tiki development would not mean decentralising the main
development and features! You could still use the cvs repository to
get 'the overview' a bit like smarty and adodb being separate in cvs,
but actually being not!
It is when 3rd party themes and modules/features are concerned, that
they need to be found elsewhere and maintained elsewhere as is the case
right now also!
tikiwiki.org or sourceforge could be used to deploy all those
featuremodules at their own pace. In fact, the rate of deployment of
a "core" module is much slower then that of most features. In fact,
it is my prediction that when you get the interlinking of features
and their awareness of eachother away, that a lot of features stabilise
faster and in the end pretty much stagnate (or close to that, going
into maintenance), since any new addition could be solved by adding
a new feature that either works with the first one as a prerequisite
or works in general (history feature, or rating or comments versus
backup/restore of wiki page objects).
Sure, you'd wind up with a lot of extra's, but at least everyone could
decide what features to use and install! You can still install all
features that you want from one monolithic install (similar in the way
tiki is deployed now). making the installer smarter to identify all
the tarballs and providing checkboxes for all those files is another
way of helping to get the best of both worlds.
> "It is a 3rd party feature unfriendly environment (you cannot just drop
> in your packages and when you use existing features hardcoded, you have
> to review them for every single release of tiki)"
> Tiki does more things "out-of-the-box" than just about any web
> application. How many more features/developers can we expect? I can't
I am not disagreeing with you here, marc! But some users get pushed into
installing (and maybe opening up back doors) stuff they do not need.
a small line of code omitted to check permissions is all it takes. Not
having files installed of things you do not use is a more certain way.
(ok, I'm paranoia at times. I'm sure there are no security issues in
tikiwiki! :-) ... but still ...)
> believe I am asking this ;-) Knowing what kind of 3rd party code we
> want to integrate will help us. What 3rd party features would you like?
stuff I have been asked by small-budget (who isn't nowadays :-))
companies are categorisable under:
- CMS stuff
- phonecall tracking
only, when I say small-budget, I mean that they have a budget to get it
made and maintained, but that they want to have it for themselves.
Since tikiwiki is LGPL, nothing stops them for making this themselves,
were it not that tikiwiki does not provide them with the knowledge to
get it to work (no api, out-of-date docs (sometimes), ...).
If you'd get those parts right: api creation and cleanup,
installer/packager, documentation-in-sync, ... you'd get a bigger
user audience from a corporate world, and a bigger possibility that
donations come back to tikiwiki. I know most of us are not in it
for the money, but as you yourself together with dennis pointed
out in the past: it could help spur some development in areas where
it is needed by some donator.
> We already integrate code from several 3rd party apps and librairies.
> What can we do to make this easier?
> Did you try the Zaufi Tiki integrator?
AFAIK TikiIntegrator is about importing static HTML (or already
generated dynamic HTML in its static form) into Wiki syntax.
A very nice feature, but hardly applicable if you want a feature
tightly integrated with tikiwiki (a view on a group's calendar for
instance, or a todo list of a group)
> Also, Galaxia has a standalone mode. This can be a good way to integrate
> 3rd party code.
When I mentioned 3rd party code, I meant 3rd party code developed for
tikiwiki, using its (future) framework. 3rd party as in: not in the
cvs repository on sf.
> AFAIK, only the *nukes have more features (and then only via 3rd party
> modules). In my past experience, this was not a "stable" solution. Some
> modules were great, some were poor. Sometimes, I would need to put off
> my Postnuke upgrade because one of my modules had not been updated. In
> Tiki, there is no need for end-users to manage module dependencies. The
> Tiki team takes care of upgrading all the themes and features.
Do we? Every now and then you see a new theme being added to the
tikiwiki codebase. Are you absolutely sure that since you enabled
others to 'write their own theme' since version 1.x (?) everyone
that did so has contributed their theme back into the cvs repository?
I think not!
As for the general idea in your answer, it crosses over as this to me:
- we frown upon extending tikiwiki by unauthorised personnel (ie 3rd
party/end-users), since our developers will do a far better job than
you finding the dependencies.
That was the entire problem in my post: get rid of the intricit
and implicit dependencies!
All modules are still in cvs. When a new core (kernel, ... whatever).
comes out, it is in fact a package with a few modules included. The ones
that are necessary to install, user managment etc. Think of the PEAR
module, CPAN (for perl), ... apt-get for debian.
Packages dependent on core = all
Luckily all the subpackages of core are version compatible (read
If the api changes (not expands, but actually would break everything
else), then increase the major number. It would increase the number
of downloads, but would also warn users: if you want to upgrade to
a new version of the api, you would have to see if all the installed
features have released an upgrade as well.
That is something you indeed could not get past. Luckily it will
only break 3rd party features, and more luckily, it would also
happen not so often. As for the features distributed by the
tikiwiki development team through sf or through tw.o, this can
be remedied in time, before a major release.
> About "limits their hosting provider pose on them. Number of files and
> total size"
> Disk space is becoming cheaper every month. I don't think this is a
> major argument in favor of major changes (and work) in Tiki.
again, I really DO have clients/users that cheap, and being
technologically impaired enough to have hosting elsewhere. Tikiwiki
is not the only app they run on their hosted site (or would run) :-)
> Tiki is a humongous application. It does lots of things. It is already
> pretty easy to install and runs on any OS, with any database and can be
> used with any browser. Similar apps such as Zope/Plone have much more
> stringent requirements and can't be installed on just about any shared
> hosting server.
Zope/Plone require just that (that the Zope server, python and the CMF
can be installed). Shared hosting is not so much the problem with them,
more than it is that it just is not provided by (m)any hosting firms at
> About making Tiki easier to install and learn, I think Dennis Heltzel's
> profiles is a superb improvement.
while profiles are great to facilitate installation and what is enabled
or not, the files still exist.
Shared hosting aside, a small hobbyist site hosted through a hosting
company that allows for the usual php/mysql pair, you'd still have a
lot of files out in the open that may or may not be secure enough.
> I am not saying we shouldn't split core vs modules. My point is that
> disk space is not a compelling argument to do so.
no, but ease of development is! I am really convinced that some features
are better off not knowing what item they belong to (rating of articles,
forum posts, comments, ... history of ...)
> I'm looking forward to more reactions and ideas on Gongo's proposal.
so do I :-)