> > I've used coWiki for a few days now. And it is excellent!
>
> We know that :-)
:) Yup, but hope you are still open for some further minor
improvements, though. ;)
> > My only single big concern is: are we gonna get ACLs
> > instead of (in addition to?) the rigid UNIX-like perms?
>
> Actually we are proud of coWikis Unix-like user/group/word
> permission system and there is not planed interducing
> ACL-permissions instead/in addition to. This would cause
> a heavy change of many parts of the coWiki core-code.
Well... I was a bit afraid of this in advance.
The Unix permission system is not a particularly sophisticated
and flexible way of handling complex access policies. It's simple,
but being simple is not always enough. And a collapboration
software is likely something that *will* often require complex
access patterns and permission control. If coWiki really aims
to become more than just a nice toy, something like ACLs will
become necessary. (I'm willing to present specific use cases
as soon as I can gather some energy to write them, but I
actually hoped that lobbying for this would never be really
necessary. ;) )
We have just installed coWiki for our small software dev.
company, for a try, and already bumping into the limitations
of the Spartan "one-user & one-group" model. The Unix people
themselves are not quite proud of that, by the way. Not only
Linux 2.6 introduces ACLs officially (2.4 patches has had
that for a long time; http://acl.bestbits.at/), but even
POSIX has defined ACLs more than 5 years ago
(http://www.watson.org/fbsd-hardening/posix1e/acl/), as
well as Samba or all the modern UNIX filesystems.
> > And a question: how can we move objects across the dir
> > tree? (If I create a dir or page at a wrong place, can
> > I restructure the tree without a) the need to copy and
> > delete, b) breaking things?)
>
> If you'd have read the TODO file which is included in you coWiki
> copy, you'd have seen, that this is planed to implement, but not
> realised yet. So there is no other choice than copy&paste your
> content to a new document and delete the old at this time.
OK, thanks! (Well, as the authors themselves say, the docs are
not quite up to par yet, so I have not trusted everything I
read. I was especially not sure about whether there is or isn't
some extra wisdom lurking around somewhere, which is not
written in the Holy Words of the Creator(s). ;) That's the
reason of my question.)
> > And a quick note: and Sergio's patch seems to be not
> > enough for PHP5 beta4. RegisterObservers bails out,
> > so I can't set a doc as a dir index, and PHP5 terminates
> > after every Edit. I don't know a thing about that part
> > unfortunately:
>
> As I have told you the last time, coWiki 0.3.3 is designed for
> PHP 5.0 beta 1 and not _any_ other version of PHP 5. Why you
> want to use another version of PHP 5?
Well, coWiki forces us to use PHP5. Now, if I had to install
PHP5 in its such an early phase, then I definitely want to install
the last PHP5 beta, because I also want to get familiar with
what will come in PHP5. Having coWiki up and running becomes
secondary to me. I care more about having a clear picture of
PHP5, and I care less about coWiki being compatible with it
or not.
If I can make it work with the latest beta with little effort,
I see no reason at all not to do it. (Remember: it *is* very
easy to get it working on beta3, especially with the help of
Sergio's patch.) If I cannot do the same with beta4, I'll just
wait with no problem. So: I do know the official word, that
it requires beta1, and I'm *not* whining about coWiki not
working with the latest beta. I'm simply sharing experience
with others (BTW, are there others on this list? ;) ), and
asking questions. (I hope you understand my motivation better
now.)
Thanks & cheers,
Sz.
--
This is the coWiki developer mailing list (http://develnet.org)
Unsubscribe: send an empty email to <cowiki-dev-unsubscribe@xxxxxxxxxxxx>
ML commands: send an empty email to <cowiki-dev-help@xxxxxxxxxxxx>
|
