Instiki users - Nov 2005 - [Instiki] About Instiki, I2, Pimki and grandmothers

I like wikis. I like their flexibility. I like their ease of use for 
grandmothers, who lived the times of ''letters'' (I recently
found out
those red boxes with a hole, which you sometimes see on the pavement, 
were used for letters. You can consider them like nodes in a network, 
and there were people who put it in this other hole you find in your 
front door.), and want to keep in touch with their grandchildren on the 
other side of the world. I like grandmothers. I like ruby, and I like 
RoR. So a while ago I started with using Instiki. Works fine. Did the 
trick, but the out-of-the box installation lacked clarity and 
customizability. And then there was Instiki AR. Same problem, but 
already on Rails and SQL. And then there is I2, which should according 
to the ''internet'' be used for larger websites with a vast
amount of
pages. And my first question (after: Not again? Doing all the changes I 
have done before?) is if Instiki AR is on Rails, and uses SQL, can there 
then be such a significant difference in implementation that Instiki AR 
could not be used for Big Sites? And then Pimki was still in the back of 
my mind. And what I really want to have is the power of I2, with the 
flexibility of Pimki (based on the features list, will soon try out). In 
PmWiki you have the CookBook, which are add-ons for the wiki. It would 
be nice if you could install the base of Instiki AR or I2, and then, at 
own wish, install for instance a todo list, or adddress book, or 
authorization modules. These might then attract more plug-in developers, 
if you give them a template to do what they want to do. I have no clue 
what this would actually mean, as my knowledge of Rails is currently 
quite poor. But it must be feasible.

Pff, I lost track of what I wanted to say. But basically it comes down 
to this: guys, put your heads together, and try to find the best of all 
three worlds (Instiki AR, I2 and Pimki), and make one beats-them-all 
wiki. These ideas shoot through my mind, at the very moment:

The wiki itself should actually be also merely a plug-in, into a top 
layer controller.
AJAX should be used heavily, probably, to control the plug-ins 
renderings in the main page
theming facilities, very attractive for new users which are not developers

I''m more then willing to contribute in these effort, as I find them
very
useful, and probably will try it out myself. But I cannot do this on my 
own, and I dont want that in the end I''ve created a YAW. Number four.
So
if people have ideas (I''m mainly looking (yes, I can see you ;-)) to
the
developers of the Trinity) on how such a system should work, shoot.

Fact: I never have written such a long mail.

regards,

Bart

Hi Bart,

A bit of History first:

- Instiki was started by David Heinemeier Hansson when he wanted to
collaborate with friends on his thesis. It was based on his ideas of
what rails will look like, and used Madeleiene object prevalence for
storage.
- I started playing with Instiki when it came out and added a few
features. DHH did not want to include them in the core as they
violated the "no step three" installation (dependencies on GraphViz)
and the simplicity of the wiki. Pimki was born.
- Being nominated "best hacker for 2005" made DHH a mite busy to take
care of Instiki and the job was given to Alexey. Alex has revamped
Instiki to use the modern rails release.
- I lost a few hairs, and decided to re-implement Pimki (as Pimki2)
because the changed were just too extensive.
- Meanwhile the RubyOnRails site was being slashdotted regularly and
the madeleine backend for the RoR wiki was crumbling. This I2 was born
- to scratch that particular itch: an Instiki-like wiki that can
withstand *really* being abused.
- Just when I thought Pimki2 was about ready, Alexey release
Instiki-AR. This is a branch of Instiki that uses adatabase for the
backend. I lost a few more hairs.
- Apparently the AR branch / beta release were successful and Alexey
has moved it to be the mainline and it will be the next Instiki
release.
- The next release will also be updated to Rails 1.0, which has a
plugin functionality.
- I''m currently waiting for the dust to settle a bit before
reimplementing, *again*, Pimki over the new Instiki. I''m still
considering what''s the best course to achieve that, especially since
Pimki is aimed at really personal use / small groups - people that
need it to "just work" without the hassle of database maintenance.

Now for your suggestions....
> The wiki itself should actually be also merely a plug-in, into a top
> layer controller.
Not sure this is possible with Rails.
Alexey has suggested I should try re-implementing Pimki as a set of
plugins as well. From a cursory glance I don''t believe that will work,
as I need to make extensive changes to the way Instiki works. For that
reason I am not sure if other non-trivial functionality can be written
as a plugin, but I am not an expert.
> AJAX should be used heavily, probably, to control the plug-ins
> renderings in the main page
Ajax is nice, but it is not a full solution to everything. Pimki2 has
a few bits of Ajax, and I think Alexey wants to do some for Instiki as
well (for the fun of it :). Am just not sure if it will solve these
issues, or make things worse.
> theming facilities, very attractive for new users which are not developers
You do have theming in the current Instik/Pimki: On the Edit Web page
you can tweak the stylesheet, or you can replace the stylesheet that
is located under /public/stylesheets in the Instiki distro. All you
need are a bit of CSS skills. (Pimki2 comes a couple of alternative
stylesheets).
> I''m more then willing to contribute in these effort, as I find
them very
> useful, and probably will try it out myself. But I cannot do this on my
> own, and I dont want that in the end I''ve created a YAW.
Feel free to submit patches to existing projects :-)


Cheers,
Assaph

At 8:59 AM +1100 11/11/05, Assaph Mehr wrote:
>Feel free to submit patches to existing projects :-)
I''d love to, but I''m kind of waiting for YOUR dust to settle. 
In
the meanwhile, I''d like to know a bit more about Pimki''s use
of
graphviz (current and projected) and "Hyberbolic Mind Maps".  Is
this stuff documented somewhere?

More generally, I''m interested in the possible crosses between
wikis and Topic Maps.  TMwiki (http://www.topic-maps.org) is one
take on this, but it sounds like Pimki could be an interesting
basis for another.

-r
-- 
email: rdm at cfcl.com; phone: +1 650-873-7841
http://www.cfcl.com        - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta   - The FreeBSD Browser, Meta Project, etc.

Hi Rich,
> >Feel free to submit patches to existing projects :-)
> I''d love to, but I''m kind of waiting for YOUR dust to
settle.
I''ll take it as a compliment :-)
> In the meanwhile, I''d like to know a bit more about
Pimki''s use of
> graphviz (current and projected) and "Hyberbolic Mind Maps".  Is
> this stuff documented somewhere?
It is documented in Pimki2 - if you have an instance running just
click on the "don''t panic" link at the top for the help
section.

In general, GraphViz is used in three places (in PImki2):
* The Mind Maps - a map of links between pages, authors and categories
in the wiki
* Hyperbolic Maps - a per-page map of inbound and outbound links
* Integrated Graphs - you can embed diagrams in a page inside
<graph></graph> tags
> More generally, I''m interested in the possible crosses between
> wikis and Topic Maps.  TMwiki (http://www.topic-maps.org) is one
> take on this, but it sounds like Pimki could be an interesting
> basis for another.
Thanks for the reference - looks interesting, I''ll check it out soon.

Cheers,
Assaph

Bart Masschelein wrote:
> Pff, I lost track of what I wanted to say. But basically it comes down 
> to this: guys, put your heads together, and try to find the best of all 
> three worlds (Instiki AR, I2 and Pimki), and make one beats-them-all 
> wiki. These ideas shoot through my mind, at the very moment:
>   
Personally, I''m trying to get rid of this horrible php-based wiki
I''m
using, and bringing Instiki up to feature parity is first on my 
development list.  I don''t actually think it''s that hard;
it''s just that
every time I post "I''m going to start working on this" to a
Rails
mailing list, I end up doing three weeks of sysadmin, and two other cool 
new projects grab my interest... so I hate to make any promises.

That said, stuff I personally intend to add to Instiki-AR if nobody gets 
there first:
- Comments
- Revision diffing
- Dojo''s WYSIWYG editor
- Table-of-contents macro
- Syntax highlighting (or is it there already? I forget)
- Basic login, probably using ModelSecurity
- Engine-ifying it
- Add field for "change description"
- Separation of "same-person edited" and "minor change"
concepts
- Better handling of back button/locking
- Preview button
- ignore-words
- Basic spam-blocking
- See if there''s a way to refactor Ruwiki and share stuff
- Page-watch e-mail notifications

Whew.  That oughta take at least a week or so.
> The wiki itself should actually be also merely a plug-in, into a top 
> layer controller.
>   
That shouldn''t be difficult at all with the new Engines stuff.
> theming facilities, very attractive for new users which are not developers
>   
I have a feeling the new rendering stuff in 1.0 is going to handle that 
nicely... we should see what develops.

Jay Levitt

Jay Levitt wrote:
> That said, stuff I personally intend to add to Instiki-AR if nobody gets 
> there first:
>   
Let''s keep in mind what Instiki is supposed to be. A personal / small 
project wiki that is ridiculously easy to install and start using. This 
actually means that there shouldn''t be many features in the
"core" of
it. I''m actually thinking about dropping some features, primarily 
Tex/PDF exports.

That said, Rails now has the plugin architecture, and so it should be 
possible for people who want to create more features to package them as 
plugins.

Looking at Jay''s list, here is my take on what is a core feature and 
what is a plugin. But if anybody feels particularly passionate about 
something, feel free to smack me down on it :)
> - Comments
>   
plugin
> - Revision diffing
>   
By all means, please make it happen. What we have now can definitely be 
smarter.
> - Dojo''s WYSIWYG editor
>   
plugin
> - Table-of-contents macro
>   
Please clarify.
> - Syntax highlighting (or is it there already? I forget)
>   
Plugin. A library to do it exists, but Instiki doesnt include it. I 
would, in fact, happily add this plugin to instiki.org.
> - Basic login, probably using ModelSecurity
>   
Plugin.
> - Engine-ifying it
>   
Hmm... not sure about it. I want to push it out the door as a standalone 
product first. If you can make a Rake task that can package reexisting 
the existing codebase into an Engine, I''m sure this would make quite a 
few people happy!
> - Add field for "change description"
>   
Plugin.
> - Separation of "same-person edited" and "minor change"
concepts
>   
Edit marked as minor by a checkbox? Plugin.
> - Better handling of back button/locking
>   
Yeah, this one could be done better than it is. Core
feature.
> - Preview button
>   
Core feature.
> - ignore-words
>   
Please clarify
> - Basic spam-blocking
>   
Already there, but should be better. And repackaged as a plugin
:)
> - See if there''s a way to refactor Ruwiki and share stuff
>   
Sure!
> - Page-watch e-mail notifications
>   
Plugin
> Whew.  That oughta take at least a week or so.
>   
Give me somebody in the Ruby world who has a spare week these days, and 
I turn over the world. :)

Best regards,
Alex

Bart Masschelein wrote:
> make one beats-them-all wiki. 
Personal and public wiki are different enough to be different projects. 
One Beats Them All Wiki will inevitably end up a horrible feature bloat, 
like PhpBB
> I''m more then willing to contribute in these effort, as I find
them very
> useful, and probably will try it out myself. But I cannot do this on my 
> own, and I dont want that in the end I''ve created a YAW.
Somebody told me recently that the right answer is: Submit Patches!
So, Submit Patches! Submit Patches! Submit Patches! :)

Alex

Alexey Verkhovsky wrote:
> Jay Levitt wrote:
>   
>> That said, stuff I personally intend to add to Instiki-AR if nobody
gets
>> there first:
>>   
>>     
> Let''s keep in mind what Instiki is supposed to be. A personal /
small
> project wiki that is ridiculously easy to install and start using. This 
> actually means that there shouldn''t be many features in the
"core" of
> it. I''m actually thinking about dropping some features, primarily 
> Tex/PDF exports.
>   
Yes, I agree.. many of these can and should be plugins.  In fact, even 
if they don''t -have- to be, designing them as such (which will take
some
refactoring of the core, I''m sure) will make it more possible for them 
to extend each other, and to work well with other extensions. 
>> - Table-of-contents macro
>>     
WackoWiki''s got this - You put {{ToC}} in a page, and it gives you a 
nicely-formatted list of the header links on the page.  It''s really, 
really nice, and takes a lot of the pressure off deciding "Should this 
stuff be refactored into multiple pages?"  See 
http://wackowiki.com/WackoDownload/InEnglish, on the rare occasions that 
it''s up...
>> - Engine-ifying it
>>   
>>     
> Hmm... not sure about it. I want to push it out the door as a standalone 
> product first. If you can make a Rake task that can package reexisting 
> the existing codebase into an Engine, I''m sure this would make
quite a
> few people happy!
>   
I was actually thinkin the other way around - once it''s an Engine,
it''s
trivial to package an app that consists only of including the engine, 
SQLite, routes, etc!
>> - Add field for "change description"
>>   
>>     
> Plugin.
>   
Hmm.. at first I disagree, but then I realize that this means we need a 
way for plugins to add fields, and I think that''s worth doing, and this
can be the simplest example of such a plugin.
>> - Separation of "same-person edited" and "minor
change" concepts
>>   
>>     
> Edit marked as minor by a checkbox? Plugin.
>   
I disagree on this one, because of the -opposite- case.  If I edit 
something three days later, I expect the wiki to store a revision for 
me, and it doesn''t.  In fact, on my wiki (and I expect on many),
I''m the
core maintainer of any page that someone doesn''t grab, so ALL the 
changes are mine...  thoughts?
>> - ignore-words
>>
>>     
> Please clarify
>   
Start writing a lot of pages about PowerBooks, MovableType, iTunes, and 
vBulletin, and you''ll very quickly wish there was a global list of
words
that were not considered WikiWords! :)  As an enhancement, it might be 
nice if they were glossary terms or something like that.  Could easily 
be a plugin.
>> - Basic spam-blocking
>>
>>     
> Already there, but should be better. And repackaged as a plugin :)
>   
Whole bunch of em, actually.. I have a list of about ten things I want 
to try eventually, culled from the various other wiki folks.  Plugins 
definitely make that easy once we have the right hooks in place.
>> Whew.  That oughta take at least a week or so.
>>   
>>     
> Give me somebody in the Ruby world who has a spare week these days, and 
> I turn over the world. :)
>   
My world keeps turning over too!

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/instiki-users/attachments/20051111/6623b344/attachment.htm

Jay Levitt wrote:
> That said, stuff I personally intend to add to Instiki-AR if nobody gets 
> there first:
<awesome list o'' stuff>

(My first post to this list, BTW.)

I''ll pop my hand up to humbly ask for a login button on the login page.
I didn''t think it was missing until I tried to use Blazer (on a Palm 
T|X) to connect to my Instiki. I can enter the password, but I can''t
hit
enter, so a login button would be much appreciated, and it shouldn''t 
slow down anyone who likes to hit enter.

Chris

PS - I like that Thunderbird suggests Nonstick as a correction of Instiki.

Interesting discussions... discovered for instance in the meantime 
Engines, how to configure fcgi correctly this time, and made a summary 
of this talk on

http://instiki.org/show/Instiki+Future+Directions

Have a look, and shoot.

bart.


Alexey Verkhovsky wrote:
>Bart Masschelein wrote:
>  
>
>>make one beats-them-all wiki. 
>>    
>>
>Personal and public wiki are different enough to be different projects. 
>One Beats Them All Wiki will inevitably end up a horrible feature bloat, 
>like PhpBB
>  
>
>>I''m more then willing to contribute in these effort, as I find
them very
>>useful, and probably will try it out myself. But I cannot do this on my 
>>own, and I dont want that in the end I''ve created a YAW.
>>    
>>
>Somebody told me recently that the right answer is: Submit Patches!
>So, Submit Patches! Submit Patches! Submit Patches! :)
>
>Alex
>
>_______________________________________________
>Instiki-users mailing list
>Instiki-users at rubyforge.org
>http://rubyforge.org/mailman/listinfo/instiki-users
>
>
>
>  
>

Chris Schumann wrote:
> (My first post to this list, BTW.)
>   
Welcome!
> I''ll pop my hand up to humbly ask for a login button on the login
page.
>   
Done (http://dev.instiki.org/changeset/424). The next release will have 
the button.

Alex