Is there any way to delete one of several wiki''s on a wiki site? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/instiki-users/attachments/20050729/255fb385/attachment.htm
Dear all, You might have noticed a lack of activity on the Instiki front in the last couple of months. At least, I''ve got some emails asking if I am still alive. The answer is "I am, but..." I''ve just changed my Real Job (TM) - joining ThoughtWorks office - and a big .NET project. Being a Java guy (as far as Real Job is concerned), I had to spend some time on learning C#, SQL Server and all those other things from Redmond WA.Which is what kept me away from hobbies such as open source programming. But finally, I''m back with you. My near term plans are: 1. Fix up instiki.org (it had a lot of downtime lately) and upgrade it to the 0.10.x version 2. Release Instiki 0.10.3 (which will cure the handling of RedCloth/BlueCloth errors, aka the "too many redirects" bug) 3. Clean up the instiki.org wiki 4. Complete the file uploads ...and then we want to try and give Instiki a real SQL backend. Best regards, Alexey Verkhovsky
And there was loud rejoicing! Thanks for the update, Alexey, and thanks to you and all the others who are helping to keep Instiki alive. I''m looking forward to my favorite wiki''s rejuvenation. Anton Alex Verhovsky wrote:> Dear all, > > You might have noticed a lack of activity on the Instiki front in the > last couple of months. At least, I''ve got some emails asking if I am > still alive. The answer is "I am, but..." > > I''ve just changed my Real Job (TM) - joining ThoughtWorks office - and > a big .NET project. Being a Java guy (as far as Real Job is > concerned), I had to spend some time on learning C#, SQL Server and > all those other things from Redmond WA.Which is what kept me away from > hobbies such as open source programming. > > But finally, I''m back with you. My near term plans are: > > 1. Fix up instiki.org (it had a lot of downtime lately) and upgrade it > to the 0.10.x version > 2. Release Instiki 0.10.3 (which will cure the handling of > RedCloth/BlueCloth errors, aka the "too many redirects" bug) > 3. Clean up the instiki.org wiki > 4. Complete the file uploads > > ...and then we want to try and give Instiki a real SQL backend. > > Best regards, > Alexey Verkhovsky > > > _______________________________________________ > Instiki-users mailing list > Instiki-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/instiki-users-- Anton Zuiker Medical journalist & weblogger http://mistersugar.com anton@zuiker.com 919.225.0969
Super! Thanks, Alex.> ...and then we want to try and give Instiki a real SQL backend. >Are you thinking of Instiki using mysql instead of Madeleine for data storage? IMO, that would be a great improvement and allow for greater flexibility of future development and add-ons. -- "Impossible is nothing."
Addressing SQL conversion ideas raised in "Re: [Instiki] I''m still alive" thread: I think we should make Instiki''s data storage method pluggable. Use the current Madeleine method as the initial implementation. Given the affordability of hardware memory, it makes sense to run a Wiki, unless truly enormous, in memory. Madeleine falls down when it comes to visibility into running or serialized data structures. The simplest solution to this problem does not necessarily imply converting to a relational database. I would prefer a file system storage implementation where each page gets a directory. The current revision exists as a plain-text textile file in that directory. Diffs, also plain-text files in the directory, give you the ability to patch back to the initial revision. Place any file uploads for that page into the same directory. On that page, allow use of simple filename for either image display or download link of one of these uploaded files. SnipSnap (http://snipsnap.org) works somewhat like that. Tam?s
On 7/29/05, Tam?s Smith <tamassmith@mac.com> wrote:> I think we should make Instiki''s data storage method pluggable.I agree. Allows for greatest flexibility.> Use the > current Madeleine method as the initial implementation.Yes and No. The beauty of madeleine is that is makes interacting with the wiki fast, and it requires no user setup. The disadvantage of Madeleine is that if anything goes wrong with your wiki - and the law of averages is that something will go wrong sometime - you could be denied access to all your data, unless you figure out a way or write something to extract it from your snapshot and recreate it. It happened to me: I must have put something in a page that Instiki didn''t like, I got the "Rails application error" and that was it. A new installation of Instiki with the snapshot copied over rendered the same result. Fortunately I was just starting the wiki. But if that happens to a user with a full-blown wiki and not only their wiki crashes but they can''t access all the data in it, you can imagine their reaction. Of course you could export to Textile or HTML every day to avoid that, but users don''t want to be burdened with that.> I would prefer a file system storage implementation where each page > gets a directory. The current revision exists as a plain-text textile > file in that directory. Diffs, also plain-text files in the directory, > give you the ability to patch back to the initial revision. > > Place any file uploads for that page into the same directory. On that > page, allow use of simple filename for either image display or download > link of one of these uploaded files. >I agree. DokuWiki (http://wiki.splitbrain.org/wiki:dokuwiki) uses a file system implementation and it works well. It''s a bit slower of course than using a database, but it has two huge advantages: - Easy data accessibility and manupulation outside the wiki. Want to move a section of your wiki somewhere else, or even to its own wiki? No problem, just move the folder (all the links within that folder will still work with each other.) - Want to rename a page? Easy, just rename the file. - Your wiki crashes and you can''t get it working? The data is still nicely in your files. You can still read it easily since it doesn''t store it in the converted HTML but the original markup format. DokuWiki supports namespaces (something that would be very nice to have in Instiki), and uses folders to represent those namespaces. I think that''s a good idea to implement as well. In DokuWiki, each wiki page in that namespace is a file in that folder. I would argue that might be simpler than each page having its own folder. Rather all of the pages under a namespace would be located in that folder. Any attachments attached to pages in that namespace would also be in that same folder. (There would be a "default" folder for pages/attachments not assigned to a namespace.) That would allow the user to reference an attachment from any page in the namespace by simply placing the file in the namespace folder (either through an simple Instiki web interface or via FTP transfer or however they want to do it). If you want to link to an attachment that''s in another namespace you just reference it by namespace:attachment or similar syntax. You could also easily have an "Attachments" link that would show all of the attachments grouped by namespace, in case you want to locate one in particular without knowing what page is referencing it. This would be a simple folder listing of all files (except the page files themselves) in your folder structure. It''ll also make it easy to implement access control to certain namespaces or pages simply by restricting access to those folders or files. Of course all of this could be acheived through mysql as well--and mysql would allow for even more possibilities and be faster. But this way the user doesn''t have to install mysql. Well, those are some ideas to get the discussion flowing. -- "Impossible is nothing."
zer0halo wrote:>Are you thinking of Instiki using mysql instead of Madeleine for data >storage? IMO, that would be a great improvement and allow for greater >flexibility of future development and add-ons. > >MySQL shall be supported. SQLite is being mentioned as a way to retain the ease of installation; which is darn useful for personal or small project wikis. MySQL would be for web sites (eg, instiki.org). Basically, there is a desire to make an ActiveRecord backend, thus completing transformation of Instiki into a textbook Rails application. Re pluggable backend. It sounds cool. Madeleine sounds cool... but in practice it''s a pain in the stern. I''m inclined to think that we "aint gonna need it". Similar story with file system storage - sorry guys, but it is not what I want to do right now. Best regards, Alexey Verkhovsky
On 7/29/05, David Guest <dpguest@bestweb.net> wrote:> Is there any way to delete one of several wiki''s on a wiki site?Not through the web interface. If you don''t mind a bit of hacking look at: http://rubyforge.org/pipermail/instiki-users/2005-May/000076.html HTH, Assaph
> But finally, I''m back with you.Glad to have you back!> ...and then we want to try and give Instiki a real SQL backend.ooh boy :-) Cheers, Assaph
Hi Alexey Can I give my $0.02 as a user not a hacker? What attracted me to Instiki (and then to Pimki) was the ease of installation for its feature set, so please make sure Instiki doesn''t become JAHW (just another heavyweight wiki!) that will require me tangling with lots of extra technology - SQLite (whatever that is) sounds encouraging. Cheers David On 7/30/05, Alex Verhovsky <alex@verk.info> wrote:> > zer0halo wrote: > > >Are you thinking of Instiki using mysql instead of Madeleine for data > >storage? IMO, that would be a great improvement and allow for greater > >flexibility of future development and add-ons. > > > > > MySQL shall be supported. SQLite is being mentioned as a way to retain > the ease of installation; which is darn useful for personal or small > project wikis. MySQL would be for web sites (eg, instiki.org<http://instiki.org> > ). > > Basically, there is a desire to make an ActiveRecord backend, thus > completing transformation of Instiki into a textbook Rails application. > Re pluggable backend. It sounds cool. Madeleine sounds cool... but in > practice it''s a pain in the stern. I''m inclined to think that we "aint > gonna need it". Similar story with file system storage - sorry guys, but > it is not what I want to do right now. > > Best regards, > Alexey Verkhovsky > > _______________________________________________ > Instiki-users mailing list > Instiki-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/instiki-users >-- David Rosam IT and SEO copywriting davidrosam@gmail.com http://dangerous-thinking.com +44 (0)70 440 ROSAM (76726) Skype:davidrosam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/instiki-users/attachments/20050730/194913df/attachment.htm
David Rosam wrote:> Hi Alexey > > Can I give my $0.02 as a user not a hacker? > > What attracted me to Instiki (and then to Pimki) was the ease of > installation for its feature set, so please make sure Instiki doesn''t > become JAHW (just another heavyweight wiki!) that will require me > tangling with lots of extra technology - SQLite (whatever that is) > sounds encouraging. > > >Boy, do I second that opinion....KISS However, I use a database, NexusDB, very fast and S!L 2003 compliant ... I''d love to be able to switch out mysql and use Nexusdb ... with an easy switch ....>------------------------------------------------------------------------ > >_______________________________________________ >Instiki-users mailing list >Instiki-users@rubyforge.org >http://rubyforge.org/mailman/listinfo/instiki-users > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/instiki-users/attachments/20050730/d1421067/attachment.htm