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

On 13 Jul 12:34, Paul Hanchett wrote:

Hi Paul,

> Daniel T. Gorski wrote:

> >Put "mysql://" instead of "mysql+innodb://" in the core.conf RESOURCE
> >entries. It will still work. But as said many timess before, the data
> >loss will come sooner or later, __especially__ if you want to have more
> >complex operations on the data base in the future.

> Daniel, it should be documented that you can DO this...  I am quite 
> frustrated by your unwillingness to document your code.

This has nothing to do with undocumented code (the coWiki code is not
documented, you are right), it has basically to do with the underlying MySQL
which wants to "make things better than intended by the programmer" as it
should.

That means: If you are trying to do a SQL "BEGIN", "COMMIT" or "ROLLBACK" on
a MyISAM database, MySQL itself won't complain: it will just do nothing, it
will swallow it.

This behaviour will lead to errors and confusion if you rely on the code
like: $SQL->begin(), $SQL->doSomething(), $SQL->rollback() OR
$SQL->commit().

You won't be able to locate misbehaviours as you don't know where they come
from. The MySQL "abstraction" in coWiki will send a "commit" command if you
are using MyISAM tables, but it won't be executed - or better - it a puff of
of warm air without any consequences. Well nobody might care usually with
"commit", but ..

... the problem arises if you use "ROLLBACK" and it is a puff of warm air
too. And coWiki uses rollback (and as I said it many times before, it will
need to use rollback in the future, if you want to implement some ideas that
are buried in the issue tracker). In this case you data will be simply
messed up in a MyISAM table and won't not usable anymore. And I do not talk
of just the "magic data loss" we have now, but of serious damage of the
database tree structure.

This is not a good outlook for a good software.

> If I have to reverse engineer it to understand how to use it, it would be
> better for me to write it as needed in the first place.

We talked about this once. It is true that the coWiki code is insufficiently
documented. We also talked about the reason, and Kai gave us a possible
solution:

The PHP code is not complied, it parsed on each request. coWiki loads a lot
of source code for _each_ request, again and again. I told you once also
about the tests where I put a dummy documentation block in front of each
method. The performace decreased dramatically as the PHP lexer (its Regular
Expressions) wasn't able to remove the unneeded documentation fast enough.

The solution suggested by Kai was to provide a documentation-ripped version
for the users. So far no mechanism has been build to achieve this. And hence
I do not see any chance of even trying to document something, because I know
that each additional byte will mean additional performace loss.

This is also the reason, why coWiki has no real accessors and mutators like
->getId() or ->setId($id), but uses a generic ->get('id')/->set('id', $id)
methods. Having real accessor methods for all required attributes will
probably slow down the performance of coWiki by 100%. It is too much code
per request - that simple. Or coWiki is too bloated, see it like you want.
 
> >You may also disable the filesystem file locking in FileOutputStream if you
> >like.

> >It's tedious. If you want, I can change the installer, so that it does
> >not stop if InnoDB is not available with a big red blinking message:
> >"Your data is not even safe on your local machine, do not use with
> >concurrent users! We guarantee the integrity of the database until your
> >first HTTP-request your fresh installed coWiki page. From then on you are
> >responsible yourself if your data messes up - coWiki is one-use, one-way
> >throwaway article. Thank you".

> Don't be silly.  If the danger is that great then any data in any wiki 
> or other application might just as well be deleted now.  If the data was 
> not safe before with concurrent users, we should just withdraw the 
> product and recommend that everyone delete their installation.  Shall we 
> publish that now?
 
No, you should publish a better (current) version, that has relied on
abstraction classes that I wrote in 1998 or 1999 where MySQL 3.23.something
(or even lower version?) was bleeding edge.

> You have lost perspective.

Maybe - maybe not. I haven't lost the sense for a bit of security of the
data I create in a collaboration tool.

> It seems to me that you are not considering other sources of error/loss
> apart from the database engine.

As stated a few times: you are probably right, that the "magic data loss" we
have now (if you refer to this here) is a programming logic problem.
Nonetheless coWiki requires a transactional database access.

> Data loss is much more likely for other reasons than a data overwrite from
> the engine.  Yes, it is theoretically possible.  Will it happen in
> practice?

Yes. Of course it will happen. Why did programmers invented transactions?

> I don't think so.  If you do, show me evidence of it.

Now, this is getting silly.

> No, I want you making well thought out responses to real threats.  Show 
> me *evidence* of a real threat here...

The threat begins with two commands to the storage container that are not
atomic.

> Telling the user: "InnoDB is not available.  We would prefer to use 
> InnoDB format because we believe that will best secure your data.  
> coWiki can also use MyISAM which is not as secure, but works well enough 
> in many cases.  Would you like us to use MyISAM instead of InnoDB?" is 
> quite enough warning and conveys what the user needs to know without the 
> fright tactics.  :-)

I can promise you, that MyISAM won't be only insecure, but destructive -
especially if concurrent users work with coWiki. And this is something you
have to believe me, as I am probably still the only one who can appraise
this.

> Yes, the installer /should /have an option to select between using 
> InnoDB and MyISAM and I should be able to select MyISAM even if InnoDB 
> is available.  Leave the user in control.

For the archives: I am strongly against this solution, but I am not the who
has to decide.

dtg