Instiki users - Oct 2005 - [Instiki] Instiki, Instiki-AR, i2 ???

I''ve seen two Instiki "forks" being floated:

On rails at lists.rubyonrails.org, Alexey Verkhovsky says that he has been
creating Instiki-AR, an ActiveRecord-based rework.

In http://dev.rubyonrails.com/file/tools/i2/README, DHH says:

   i2 is small, tight rewrite of Instiki as a native Rails application
   that runs [off] of a database instead of Madeleine.  It''s better
   suited for big, public wikis with lots of pages.  But it requires
   more manual work to set up.

The activity is interesting, but I''m a bit concerned that
we''ll end
up with three (or more) Instiki variants, each on its own fork.  Is
there any chance for a reconciliation (:-)?

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

> The activity is interesting, but I''m a bit concerned that
we''ll end
> up with three (or more) Instiki variants, each on its own fork.  Is
> there any chance for a reconciliation (:-)?
I''m thinking there are two different tracks. The original vision for  
Instiki was personal/group wikis where you don''t have all those  
problems like big wikis do (like spam, etc), but on the other hand  
you want zero setup time.

I made the mistake of using Instiki, which is meant for the personal  
wiki, on big public sites like the Rails wiki. That''s just a bad fit.  
So I see i2/Instiki-AR as a different track.

And I''d like to see them evolve more into those niches.
--
David Heinemeier Hansson
http://www.37signals.com    -- Basecamp, Backpack, Writeboard, Tada
http://www.loudthinking.com -- Broadcasting Brain
http://www.rubyonrails.com  -- Web-application framework

On Wed, 2005-10-05 at 12:01 -0700, david at loudthinking.com (David Heinemeier
Hansson) wrote:
> I''m thinking there are two different tracks. The original vision
for
> Instiki was personal/group wikis where you don''t have all those  
> problems like big wikis do (like spam, etc), but on the other hand  
> you want zero setup time.
> 
> I made the mistake of using Instiki, which is meant for the personal  
> wiki, on big public sites like the Rails wiki. That''s just a bad
fit.
> So I see i2/Instiki-AR as a different track.
Ours is neither a personal wiki, nor a big public site like the Rails
wiki.  Instead, it is to be an internal wiki for our company.  As such,
it will start out small, but could grow to be quite large if it catches
on.  We''re thinking we will eventually need i2 or Instiki-AR, but with
such uncertainty about the future of these projects, it seems it is best
to stick with Instiki until we see which one succeeds.

We''re assuming the Instiki project is going to make it easy for us to
make the switch when the time comes.  How would you migrate from Instiki
to one of these forks today, and is it likely to be very much the same
procedure when the time comes to switch?

Regards,
Ben Armstrong

BG - Ben Armstrong wrote:
>We''re thinking we will eventually need i2 or Instiki-AR, but with
>such uncertainty about the future of these projects, it seems it is best
>to stick with Instiki until we see which one succeeds.
>  
>
I''m actually working on both Instiki-AR and I2 right now. They are not 
forks. Instiki-AR will be merged into the trunk soon (translation for 
non-programmers: eventually it will become Instiki 0.11 release). I2 is 
is a new project, which at the moment is defined is "tailor-made wiki 
engine for www.rubyonrails.org", no more, no less. Large, public wiki, 
constantly spammed, occasionally slashdotted, and all that jazz.

If I were looking for an internal project wiki now, I''d probably use 
Instiki-AR. I know some people using beta 1 and saying that it "just 
works". For your scenario the installation process does not need to be 
as simple as "download, start, voila", therefore you may want to begin
right there. Beta 2 is "Coming Real Soon", in open-source terms.
>We''re assuming the Instiki project is going to make it easy for us
to
>make the switch when the time comes. How would you migrate from Instiki
>to one of these forks today, and is it likely to be very much the same
>procedure when the time comes to switch?
>  
>
Instiki -> Instiki-AR migration script packaged with Beta 1 is good 
enough. Just don''t forget to run
''script/reset_references''.
I2 migration is considerably worse, and it will probably stay that way, 
simply because rubyonrails.org doesn''t need a migration script anymore.
Having said that, somebody may just read this and write one for the heck 
of it (or for his/her own needs) :) In which case, please submit a patch 
to dev.rubyonrails.org!

Best regards,
Alexey Verkhovsky

> Instiki-AR will be merged into the trunk soon (translation for
> non-programmers: eventually it will become Instiki 0.11 release).
...
> Beta 2 is "Coming Real Soon", in open-source terms.
Can you please comment about the scope of (planned) changes?
(Won''t hold you to any timeframe, just a roadmap of what you want to
achieve for the next few versions :-)

Cheers,
Assaph

Assaph Mehr wrote:
>Can you please comment about the scope of (planned) changes?
>  
>
>(Won''t hold you to any timeframe, 
>
Thanks, Assaph, I really appreciate this. :)
>a roadmap of what you want to
>achieve for the next few versions :-)
>  
>
- Get rid of Madeleine
- Upgrade to Rails 1.0; presumably, this should enable you to repackage 
Pimki as plugins (if that''s what you want to do); it will also let
other
people publish plugins for whatever.
- CSS tweaks to replace hard-coded pixel-based styles with something 
less rigid
- File uploads (now THAT''S an old song, isn''t it?)

I also want to do some AJAX, just for the heck of it. Don''t know what
it
will be yet, probably in the file uploads area.
This is as far as I see now. For all we know today, I may then retire to 
Inner Mongolia and live peacefully ever after... but this is unlikely :)

Alex

hi,
> - Get rid of Madeleine
> - Upgrade to Rails 1.0; presumably, this should enable you to repackage
> Pimki as plugins (if that''s what you want to do); it will also let
other
> people publish plugins for whatever.
> - CSS tweaks to replace hard-coded pixel-based styles with something
> less rigid
> - File uploads (now THAT''S an old song, isn''t it?)
>
> I also want to do some AJAX, just for the heck of it. Don''t know
what it
> will be yet, probably in the file uploads area.
I''d prefer theming instead of just CSS, i always had this idea of a
plugin for importing wordpress themes to instiki :S, right now its
just a weird idea. The ajax interface to instiki could just be a
theme. so if the browser is not XTML compatible, you could just load a
diff theme.
Problem is , I''m just learning my way around ruby and its been a few
years since i tried to learn a new lang. so it aint happening anytime
soon :(

BKR

(moved discussion here as it''s probably more appropriate)

Hi Alexy,

Mostly I want to know how much you think the code base is due to
change between beta1, beta2 and Instiki 1.0 (or 0.11 if you insist ;)
>- Get rid of Madeleine
>- Upgrade to Rails 1.0;
I thought these were mostly done in beta1, no?
I did see some comments in the code that you expect to change it (e.g.
the page renderer). How much of this is in there?
> presumably, this should enable you
> to repackage Pimki as plugins (if that''s what you want to do);
Am not sure this will be enough. I plan to do some extensive
modifications of the data-model and page content handling (embedding
objects in it), so I don''t believe a simple plugin will be enough. And
since SQLite doesn''t support migrations, it also seems like
it''ll have
to be a more permanent fork - not something I expected to do.

> This is as far as I see now. For all we know today, I may then retire to
> Inner Mongolia and live peacefully ever after... but this is unlikely :)
I dunno, I never could get used to the taste of Yak cheese :-)

Cheers,
Assaph

Assaph Mehr wrote:
>>- Get rid of Madeleine
>>- Upgrade to Rails 1.0;
>>    
>>
>I thought these were mostly done in beta1, no?
>  
>
Yes for Madeleine, not completely for Rails 1.0. Since beta1 the AR 
branch has undergone some changes, such as 0.14.2 script/*, public/*, 
db/* and config/*. Rakefile.rb, too. All this to make it a "usual Rails 
experience" for any would-be developer as much as possible.
>I did see some comments in the code that you expect to change it (e.g.
>the page renderer). How much of this is in there?
>  
>
For now, I do not plan to change it at all. I don''t particularly like 
the chunks stuff (because it is so much extra complexity), but it works 
and I don''t plan to rebuild it. At least, not until there is RedCloth 
that supports Markdown in a consistent way - and that will probably 
never happen.
>>presumably, this should enable you
>>to repackage Pimki as plugins (if that''s what you want to do);
>>    
>>
>Am not sure this will be enough. I plan to do some extensive
>modifications of the data-model and page content handling (embedding
>objects in it), so I don''t believe a simple plugin will be enough.
And
>since SQLite doesn''t support migrations, it also seems like
it''ll have
>to be a more permanent fork - not something I expected to do.
>  
>
In fact, I''m telling everybody nowadays that although Instiki-AR will
be
prepackaged with SQLite, in any serious scenario it is best to use it 
with MySQL. For that very reason.

Alex

Hi Alexey,

Thanks for sharing your experiences.
>> ... And since SQLite doesn''t support migrations...
>
> In fact, I''m telling everybody nowadays that although Instiki-AR
will be
> prepackaged with SQLite, in any serious scenario it is best to use it
> with MySQL. For that very reason.
I think we deserve a big d''oh!
I mucked about a bit in the AR code, and it looks like SQLite does
support Schema and Migrations. The docos says no, but the code says
yes :-)

For my purposes MySQL is not an option. Even though SQLite can be good
enough, I am still interested in seeing if I can make an AR adapter
for KirbyBase - a pure ruby plain text DBMS. It doesn''t support SQL
(because it doesn''t need to), so I am not sure I will be able to make
it work. But if I can it should be great - one less external
dependency.

Your thoughts and comments are most welcome.

Cheers,
Assaph

> I mucked about a bit in the AR code, and it looks like SQLite does
> support Schema and Migrations. The docos says no, but the code says
> yes :-)
And as proof, attached is a schema.rb file that implements the db
schema from beta1. You can create a database by: rake db_schema_import
This will happily create the sqlite dbs.

The schema also includes a couple of tweak I''d be happy if they were
incorporated in the main line. Hope you like this patch :-)

Cheers,
Assaph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schema.rb
Type: application/octet-stream
Size: 1789 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/instiki-devel/attachments/20051110/c4707b86/schema.obj

Hi Alexey,
> And as proof, attached is a schema.rb file that implements the db
> schema from beta1.
Double d''oh!
I tried to get a latest version of Instiki svn, but the server seems
to be down. I checked it out and the Trac browser is up.... and I saw
you already implemented a schema.rb file.

Alexey, you should really start blogging about your Instiki progress :-)

Cheers,
Assaph

Assaph Mehr wrote:
> Alexey, you should really start blogging about your Instiki progress :-)
>   
This is my blog:
  http://dev.instiki.org/timeline
:)

Alex

> This is my blog:
>   http://dev.instiki.org/timeline
> :)
Cute :-P
Is there a way to get email notifications of checkins? Or an RSS feed
of changesets?

Cheers,
Assaph

Assaph Mehr wrote:
>> This is my blog:
>>   http://dev.instiki.org/timeline
>> :)
>>     
> Cute :-P
> Is there a way to get email notifications of checkins? Or an RSS feed
> of changesets?
>   
Of course! If you look at the HTML head tag of that page, you''ll see
this:

  <link rel="alternate"
href="?daysback=90&amp;max=50&amp;wiki=on&amp;ticket=on&amp;changeset=on&amp;milestone=on&amp;format=rss"
title="RSS Feed" type="application/rss+xml" />


It is an auto-discovery link for the RSS feed to the Trac timeline.

Alex

> Of course! If you look at the HTML head tag of that page, you''ll
see this:
>
>   <link rel="alternate"
href="?daysback=90&amp;max=50&amp;wiki=on&amp;ticket=on&amp;changeset=on&amp;milestone=on&amp;format=rss"
title="RSS Feed" type="application/rss+xml" />
>
>
> It is an auto-discovery link for the RSS feed to the Trac timeline.

Great! Thanks.
Now I just have to wait for interesting updates ;-)

Cheers,
Assaph

Hi all,

I''ve had Instiki running and I want to get it running again on a new 
machine... but I have a few questions I hope you can help with.

- Does Instiki really need its own web server? I''ve already got Apache 
running and would like to avoid WEBrick if possible. I guess a port of 
Instiki to some kind of Ruby layer for Apache would be required. Yay.

- What''s the best way to run several Instiki''s on the same
machine?

- If I want to have several Rails applications running, what''s the best
way to install Instiki? (I''m guessing just install the gem package, but
want to be sure.)

Many thanks,
Chris

Hi Chris,

> - Does Instiki really need its own web server? I''ve already got
Apache
> running and would like to avoid WEBrick if possible. I guess a port of
> Instiki to some kind of Ruby layer for Apache would be required. Yay.
You can use apache - the instructions are on instiki.org, which is
down at the moment
(maybe try google cache until alexey kicks the server)

> - What''s the best way to run several Instiki''s on the
same machine?
Two options:
1) Multiple webs: go to the "edit web" from the home page, and near
the bottom there is a link to create another web. You can then access
them as, e.g.: http://localhost:2500/myfirstweb/ and
http://localhost:2500/mysecondweb/

2) Multiple instiki processes, each bound to a different port: use the
--port commandline parameter. You will access them as, e.g.:
http://localhost:2500/myfirstweb/ and http://localhost:2501/mysecondweb/
> - If I want to have several Rails applications running, what''s the
best
> way to install Instiki? (I''m guessing just install the gem
package, but
> want to be sure.)
Gems are usually the prefered way.... at least until Alexey packages
Instiki-AR (now on the mainline). If you want to run several Rails
apps on one server (including instiki), all with different databases I
assume, you should take a look at the RoR wiki (e.g.
http://wiki.rubyonrails.com/rails/pages/HowtoUseSymLinksToGraftRailsOntoYourWebsite).
I hope you know your apache magic well, because it''s wayy over my
knowhow.

Cheers,
Assaph

Assaph Mehr wrote:
> Hi Chris,
Hello Assaph! Thanks for the quick reply.
>> - Does Instiki really need its own web server? I''ve already
got Apache
>> running and would like to avoid WEBrick if possible. I guess a port of
>> Instiki to some kind of Ruby layer for Apache would be required. Yay.
> 
> You can use apache - the instructions are on instiki.org, which is
> down at the moment
> (maybe try google cache until alexey kicks the server)
Looking at the cache, and from my memory, from these instructions, 
apache acts as a proxy for WEBrick. I would like to avoid having two web 
servers running on my meager server, and apache has to stay.

I''d like to better understand why Instiki uses WEBrick, how it uses its
web server, and how it might be ported to apache.
>> - What''s the best way to run several Instiki''s on the
same machine?
> 
> Two options:
> 1) Multiple webs: go to the "edit web" from the home page, and
near
> the bottom there is a link to create another web. You can then access
> them as, e.g.: http://localhost:2500/myfirstweb/ and
> http://localhost:2500/mysecondweb/
> 
> 2) Multiple instiki processes, each bound to a different port: use the
> --port commandline parameter. You will access them as, e.g.:
> http://localhost:2500/myfirstweb/ and http://localhost:2501/mysecondweb/
These are great tips. Thanks. Unfortunately, it looks like my workplace 
recently blocked access to 2500, so I''ll have to dig into the
httpd.conf
and mod_rewrite voodoo, but that''s OK.
>> - If I want to have several Rails applications running, what''s
the best
>> way to install Instiki? (I''m guessing just install the gem
package, but
>> want to be sure.)
> 
> Gems are usually the prefered way.... at least until Alexey packages
> Instiki-AR (now on the mainline). If you want to run several Rails
> apps on one server (including instiki), all with different databases I
> assume, you should take a look at the RoR wiki (e.g.
>
http://wiki.rubyonrails.com/rails/pages/HowtoUseSymLinksToGraftRailsOntoYourWebsite).
> I hope you know your apache magic well, because it''s wayy over my
> knowhow.
That''s all very good to know. I''ve done some apache voodoo
with good
outcomes so far. I''m also planning on developing a new rails 
application, so this could be a lot of fun!

Chris

Hi Chris,

> Looking at the cache, and from my memory, from these instructions,
> apache acts as a proxy for WEBrick. I would like to avoid having two web
> servers running on my meager server, and apache has to stay.
>
> I''d like to better understand why Instiki uses WEBrick, how it
uses its
> web server, and how it might be ported to apache.
I guess that might be easier when the next version of Instiki comes
out, as it will be a more "traditional" rails app. I believe it should
be much easier to setup over apache then.

Instiki uses WEBrick as a zero-install, zero-config web server - it''s
there in he ruby stdlib. The assumption is that Instiki is aimed at
the "low-end" when for most people it''s enough.

> > I hope you know your apache magic well, because it''s wayy
over my
> > knowhow.
>
> That''s all very good to know. I''ve done some apache
voodoo with good
> outcomes so far. I''m also planning on developing a new rails
> application, so this could be a lot of fun!
Feel free to update the wiki :-)

Cheers,
Assaph

The Instiki-AR version can be installed to run with Apache as the server. I
documented my successful install at
http://stratventures.com/wiki/site5install/


On 12/6/05, Assaph Mehr <assaph at gmail.com>
wrote:
>
> Hi Chris,
>
>
> > Looking at the cache, and from my memory, from these instructions,
> > apache acts as a proxy for WEBrick. I would like to avoid having two
web
> > servers running on my meager server, and apache has to stay.
> >
> > I''d like to better understand why Instiki uses WEBrick, how
it uses its
> > web server, and how it might be ported to apache.
>
> I guess that might be easier when the next version of Instiki comes
> out, as it will be a more "traditional" rails app. I believe it
should
> be much easier to setup over apache then.
>
> Instiki uses WEBrick as a zero-install, zero-config web server -
it''s
> there in he ruby stdlib. The assumption is that Instiki is aimed at
> the "low-end" when for most people it''s enough.
>
>
> > > I hope you know your apache magic well, because it''s
wayy over my
> > > knowhow.
> >
> > That''s all very good to know. I''ve done some apache
voodoo with good
> > outcomes so far. I''m also planning on developing a new rails
> > application, so this could be a lot of fun!
>
> Feel free to update the wiki :-)
>
> Cheers,
> Assaph
>
> _______________________________________________
> Instiki-users mailing list
> Instiki-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/instiki-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/instiki-users/attachments/20051207/c04cb6a5/attachment-0001.htm