Re: [cowiki-dev] Releasing coWiki with the "working" parser

My responses are inline!

Daniel T. Gorski wrote:

>On 11 Jul 07:44, Paul Hanchett wrote:
>...
>  
>
>>My point is that
>>
>>   * The development team has scratched some technological issues that
>>     (under normal circumstances) make absolutely no difference to users.
>>    
>>
>
>Sure? This has been not verified.
>  
>
Think about it.  It *CAN'T* be a corruption problem-- It requires that 
code execute correctly to leave an intact previous page.  There is only 
one function in all of coWiki devoted to performing this function, and 
it is called from exactly one place in code.  Seems a lot more likely to 
be a coding error of some kind.  Not at all an acid type error.

>>   * There are no performance enhancements or changes to "pay" for the
>>     effort of upgrading.
>>    
>>
>
>Yes. Even the opposite is the case, the performanse should decrease: that's
>the price for InnoDB.
>
>  
>
>>   * If Boron wasn't adequate for a task, then neither will be
>>     Fullerene (at this point).
>>    
>>
>
>Hance the suggestion for a RC. The ChangeLog reflects a few issues.
>  
>
I don't follow the logic?  Fullerene is no better than Boron so we'll do 
a release anyway?  Besides, if someone wants a new feature all they have 
to do is pull it from CVS.  If we want to release for RC we will have to 
QA what we have done so far (not necessarily bad) /knowing/ this we are 
working on a _throwaway_ version (this really sucks and is bad for [my] 
morale!)

>>   * The most we can claim to have is a "Bug-fix" release.  As such,
>>     except for the database incompatibility, the most we can claim is
>>     0.3.5...
>>    
>>
>
>I though about 0.3.5 first, but realised that the migration to InnoDB is not
>a "micro" change.
>  
>
My thoughts were the same.  Unless we can make InnoDB backwards 
compatible (i.e., downgrade to MyISAM with the attendant implications 
re: reliability) we can't call it 0.3.5.  I would be happy to do a 0.3.5 
release cycle (with the old parser if that's what it takes) if this 
requirement were met.  What would you have to do in the database?

>>BTW, with the INNODB database requirement, there are quite a few places 
>>we will no longer run.  As has been noted, XAMPP no longer works, and 
>>frankly I wonder why we have paid this price...
>>    
>>
>
>We didn't pay any price yet, as no one uses CVS HEAD. The price we will have
>to pay someday is the price for a more stable application. And this should
>bother you, it's a good price.
>  
>
You mean "not" bother me, right?  The problem is that InnoDB is not 
standard in the hosting community.  MyISAM may not be reliable enough to 
put the corporate jewels into, but it's plenty good enough for 90% of 
the net. 

>>I know the effort was to get database reliability because of the "Magic"
>>problem, but it has been demonstrated with the new code so I am as ready
>>to roll back the database as you are the parser.
>>    
>>
>
>The database stuff works (even if the XAMPP guys are not able to set a
>config parameter right in their setup - to be honest I never heard of XAMPP
>before Sy mentioned it). On the other hand the parser does not work ask
>expected. This can not be compared.
>  
>
Well, I'm unhappy over the XAMPP thing-- It's the easiest way to have 
Apache, PHP5 and MySQL all running on the same system.  XAMPP is the 
successor to WAMP and LAMP running on Windows and Linux respectively.  
It's a good thing and I don't want to bad mouth them.  I finally 
resolved the issue by installing the full MySQL and then installing 
XAMPP and letting XAMPP's install of MySQL fail.  It works but it's not 
very clean.

>>I say "Fix the database AND the parser before the next release."
>>    
>>
>
>+1, yes, the migration to InnoDB was the first big step for fixing the
>database - and as already said, it works (except the magic-bug, that might
>or might not have something to do with it). The parser, as can be seen on
><http://dev.cowiki.org>, stumbles on small issues.
>  
>
Bet you a beer that InnoDB does not really fix the problem (though I 
will hedge the bet with "although it may change how the problem shows 
itself.")  :-)

>>I also don't see any reason that, if InnoDB isn't available why we can't
>>fall back to MyISAM and simply forgo ACID quality transactions.
>>    
>>
>
>Sure you can, but earlier or later data loss will be the result. I can not
>imagine, that this is what you want. coWiki manages a tree not a simple
>guestbook entry.
>  
>
As I mentioned before, I don't think we are seeing this sort of problem 
anyway.  People are using MyISAM for far more critical applications than 
a wiki without problems.  Sure storage is less reliable, but is it 
*that* much less reliable.  I think the answer is "No."  But that is 
opinion.

Paul