Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Most popular wiki in Ruby seeks kind maintainer

Reply
Thread Tools

Most popular wiki in Ruby seeks kind maintainer

 
 
David Heinemeier Hansson
Guest
Posts: n/a
 
      11-23-2004
Okay, okay, okay. Instiki does need a new maintainer. At least a
temporary steward until I'm ready to resume that role. Are you it?

The kick: Instiki just surpassed 8,000 downloads on RubyForge, which
makes it the most downloaded piece of software there if you don't count
Ruby itself.

But Instiki has special needs, which is why I've been hesitant to call
for a maintainer. See, Instiki needs to be and do less. But do it
better.

So while all the pending patches are pretty cool in one aspect or
another, they're mostly about adding stuff to Instiki.

Here's what I'd like a new Instiki maintainer to work on:

* Fix the bugs. There are quite a few. Especially render bugs.

* Switching from Marshal to YAML outputs. The biggest fear in Instiki
is that something horrible goes wrong with the persisted data and all
is lost in a big ball of Marshalled, binary mud. Having a humanly
readable format would be very nice. This needs A LOT of testing,
though.

* Image uploads... perhaps even file uploads. This one is really
tricky, though. It's very easy to create a big honking thing. We need
an Instiki approach to the problem. Bill Atkins and I already had a few
thoughts on the subject.

Who's willing for glory and honor?
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain



 
Reply With Quote
 
 
 
 
Alexey Verkhovsky
Guest
Posts: n/a
 
      11-23-2004
David Heinemeier Hansson wrote:

> Okay, okay, okay. Instiki does need a new maintainer. At least a
> temporary steward until I'm ready to resume that role. Are you it?



David,

As I said in the chat, I'm sure somebody more qualified than me will
take it up. But just in case nobody does, I can.

Alex


 
Reply With Quote
 
 
 
 
Austin Ziegler
Guest
Posts: n/a
 
      11-23-2004
On Wed, 24 Nov 2004 02:35:21 +0900, David Heinemeier Hansson
<(E-Mail Removed)> wrote:
> * Switching from Marshal to YAML outputs. The biggest fear in Instiki
> is that something horrible goes wrong with the persisted data and all
> is lost in a big ball of Marshalled, binary mud. Having a humanly
> readable format would be very nice. This needs A LOT of testing,
> though.


I recommend *not* using YAML. In my experiences with Ruwiki, YAML support is
not yet stable enough -- especially for large data -- for general use.

-austin, trying to get some of these same features in Ruwiki...
--
Austin Ziegler * http://www.velocityreviews.com/forums/(E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Francis Hwang
Guest
Posts: n/a
 
      11-24-2004
More generally, let me ask: What formats are people using to persist
Ruby objects to disk? What are pluses and minuses? I can't figure out
when I should use something like YAML and when I should use the Marshal
module and if there's anything else out there that people are using,
I'm probably going to get sort of confused but should probably hear
about them anyway.

On Nov 23, 2004, at 4:49 PM, Austin Ziegler wrote:

> On Wed, 24 Nov 2004 02:35:21 +0900, David Heinemeier Hansson
> <(E-Mail Removed)> wrote:
>> * Switching from Marshal to YAML outputs. The biggest fear in Instiki
>> is that something horrible goes wrong with the persisted data and all
>> is lost in a big ball of Marshalled, binary mud. Having a humanly
>> readable format would be very nice. This needs A LOT of testing,
>> though.

>
> I recommend *not* using YAML. In my experiences with Ruwiki, YAML
> support is
> not yet stable enough -- especially for large data -- for general use.
>
> -austin, trying to get some of these same features in Ruwiki...
> --
> Austin Ziegler * (E-Mail Removed)
> * Alternate: (E-Mail Removed)
>
>


Francis Hwang
http://fhwang.net/



 
Reply With Quote
 
Lothar Scholz
Guest
Posts: n/a
 
      11-24-2004
Hello Francis,

FH> More generally, let me ask: What formats are people using to persist
FH> Ruby objects to disk? What are pluses and minuses? I can't figure out
FH> when I should use something like YAML and when I should use the Marshal
FH> module and if there's anything else out there that people are using,
FH> I'm probably going to get sort of confused but should probably hear
FH> about them anyway.

If you want a readable object file that can edited by a human
(configuration file) use YAML otherwise use Marshal.

You can read YAML file also with Python, Perl und PHP applications

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's




 
Reply With Quote
 
Francis Hwang
Guest
Posts: n/a
 
      11-24-2004

On Nov 23, 2004, at 9:41 PM, Lothar Scholz wrote:

> Hello Francis,
>
> FH> More generally, let me ask: What formats are people using to
> persist
> FH> Ruby objects to disk? What are pluses and minuses? I can't figure
> out
> FH> when I should use something like YAML and when I should use the
> Marshal
> FH> module and if there's anything else out there that people are
> using,
> FH> I'm probably going to get sort of confused but should probably hear
> FH> about them anyway.
>
> If you want a readable object file that can edited by a human
> (configuration file) use YAML otherwise use Marshal.
>
> You can read YAML file also with Python, Perl und PHP applications
>


Why wouldn't I just use YAML all the time? Are there certain types of
classes that aren't going to turn into YAML well? Stability issues with
YAML libs? (I've mostly used Marshal in the past, so pardon if my YAML
questions are naive.)

Francis Hwang
http://fhwang.net/



 
Reply With Quote
 
John Wilger
Guest
Posts: n/a
 
      11-24-2004
What's wrong with good old fashined XML? Isn't this sort of thing what
XML was designed for?


On Wed, 24 Nov 2004 12:07:07 +0900, Francis Hwang <(E-Mail Removed)> wrote:
>
>
>
> On Nov 23, 2004, at 9:41 PM, Lothar Scholz wrote:
>
> > Hello Francis,
> >
> > FH> More generally, let me ask: What formats are people using to
> > persist
> > FH> Ruby objects to disk? What are pluses and minuses? I can't figure
> > out
> > FH> when I should use something like YAML and when I should use the
> > Marshal
> > FH> module and if there's anything else out there that people are
> > using,
> > FH> I'm probably going to get sort of confused but should probably hear
> > FH> about them anyway.
> >
> > If you want a readable object file that can edited by a human
> > (configuration file) use YAML otherwise use Marshal.
> >
> > You can read YAML file also with Python, Perl und PHP applications
> >

>
> Why wouldn't I just use YAML all the time? Are there certain types of
> classes that aren't going to turn into YAML well? Stability issues with
> YAML libs? (I've mostly used Marshal in the past, so pardon if my YAML
> questions are naive.)
>
>
>
> Francis Hwang
> http://fhwang.net/
>
>



--
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland


 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      11-24-2004
On Wed, 24 Nov 2004 11:29:51 +0900, Francis Hwang <(E-Mail Removed)>
wrote:
> More generally, let me ask: What formats are people using to
> persist Ruby objects to disk? What are pluses and minuses? I can't
> figure out when I should use something like YAML and when I should
> use the Marshal module and if there's anything else out there that
> people are using, I'm probably going to get sort of confused but
> should probably hear about them anyway.


Well, I should qualify my statements some, because I don't want to
maling _why's work, which is nothing short of amazing, ultimately.
For short configuration items, YAML is rather impressive. It is
human editable, it's rich, and it's reasonably stable.

However, syck -- the YAML parser built into Ruby -- is unusable in
Ruby 1.8.1 (which is still the officially released version of Ruby)
on Windows and has other issues in versions of Ruby up through 1.8.2
preview 2. I have not yet verified whether the problems I had in
1.8.2p2 with syck have been fixed, and I've not been in a position
to verify them lately.

Ruwiki has specific needs that may or may not be present in a
generic application that needs something externally editable. In
particular, Ruwiki files can be large because of the content --
which is a large \n-delimited string. For a Ruwiki file at work and
for the Ruwiki::WikiMarkup pages, syck failed (as in coredump) in
Ruby 1.8.1 on Windows on writing strings longer than about 7k and
reading strings longer than about 4k. I don't think it was a
Windows-only problem. In Ruby 1.8.2p2, syck was confused by \n and
sometimes escaped them when it shouldn't, resulting in unusable
code.

Because of this, and because I needed a human-editable format that
was simple, reasonably quick, and reliable, I created what has since
become Ruwiki::Exportable. This is a general-purpose markup, but it
is not a type-smart format (like YAML), leaving it up to the reader
and the writer to ensure that the data it writes out will be
meaningfully read back in. The format looks something like (this is
actually the default ruwiki.conf):

ruwiki-config!css: ruwiki.css
ruwiki-config!date-format: %Y.%m.%d
ruwiki-config!datetime-format: %Y.%m.%d %H:%M:%S
ruwiki-config!debug: true
ruwiki-config!default-page: ProjectIndex
ruwiki-config!default-project: Default
ruwiki-config!language: en
ruwiki-config!storage-options: flatfiles!data-path: ./data
flatfiles!extension: ruwiki
ruwiki-config!storage-type: flatfiles
ruwiki-config!template-path: ./templates/
ruwiki-config!template-set: default
ruwiki-config!time-format: %H:%M:%S
ruwiki-config!title: Ruwiki
ruwiki-config!webmaster: (E-Mail Removed)
webrick-config!addresses:
webrick-config!do-log: true
webrick-config!log-dest: <STDERR>
webrick-config!mount: /
webrick-config!port: 8808
webrick-config!threads: 1

When read, this will look like (in Ruby):

{ 'ruwiki-config' =>
{ 'css' => 'ruwiki.css',
'date-format' => "%Y.%m.%d",
#...
},
'webrick-config' =>
{ 'addresses' => "",
#...
}
}

I have to know that webrick-config!addresses resulting in ""
actually means []. I have to know in a .ruwiki file that
"properties!edit-date: 1101267172" actually means "Tue Nov 23
22:32:52 Eastern Standard Time 2004" because it's Time.now.to_i.

I also have to know that the value listed for "storage-options" is
actually a nested Ruwiki::Exportable document. The formal definition
for a Ruwiki::Exportable document is:

<group-id>!<item-id>:<1whitespace>VALUE
[<1whitespace>CONTINUED VALUE]*

That is, if I want to continue a value, I simply continue it by not
specifying another <group-id> at the beginning and indenting the
embedded value with ONE whitespace -- either a tab or a space (it
was originally only tabs, which is still what Ruwiki::Exportable
uses by default on export to string).

YAML knows some of the type stuff -- and most of the problems I have
seen are when syck is wrong on that guess or otherwise mangles it.

I'm actually quite pleased with Ruwiki::Exportable -- it's
reasonably fast and simple to understand, but it is one level
separated from the actual object (it uses a hash as the canonical
format for the data, not the object itself, as Marshal and YAML do).

I prefer YAML to XML for most editable configuration files, but YAML
has its own issues.

-austin

> On Nov 23, 2004, at 4:49 PM, Austin Ziegler wrote:
>> On Wed, 24 Nov 2004 02:35:21 +0900, David Heinemeier Hansson
>> <(E-Mail Removed)> wrote:
>>> * Switching from Marshal to YAML outputs. The biggest fear in
>>> Instiki is that something horrible goes wrong with the
>>> persisted data and all is lost in a big ball of Marshalled,
>>> binary mud. Having a humanly readable format would be very
>>> nice. This needs A LOT of testing, though.

>> I recommend *not* using YAML. In my experiences with Ruwiki, YAML
>> support is not yet stable enough -- especially for large data --
>> for general use.

--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Lothar Scholz
Guest
Posts: n/a
 
      11-24-2004
Hello John,

JW> What's wrong with good old fashined XML? Isn't this sort of thing what
JW> XML was designed for?

Yes, it's only there because some people like the YAML flavour a
little bit more then old fashined XML.

It is easier to read and it is more dense. Also it does not try to do
sophisticated things like namespaces etc.

But i never used it, i also prefer good old fashined XML.

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's




 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      11-24-2004
On Wed, 24 Nov 2004 12:30:11 +0900, John Wilger <(E-Mail Removed)> wrote:
> What's wrong with good old fashined XML? Isn't this sort of thing what
> XML was designed for?


The biggest problem with XML is verbosity and impedance mismatch with
Ruby objects for Marshal-ing.

-austin
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wiki engine used by Ruby Wiki? Robert Oschler Ruby 3 06-25-2004 09:45 AM
Re: Python Wiki & wiki Hosting? Eric S. Johansson Python 6 06-08-2004 08:39 AM
RE: Python Wiki & wiki Hosting? Mahrt, Dallas Python 0 06-07-2004 09:52 PM
Python Wiki & wiki Hosting? Eric @ Zomething Python 2 06-05-2004 09:23 PM
general Wiki format question and Python Wiki markup parsing libraries chris Python 4 05-17-2004 05:27 PM



Advertisments