On 01/10/2012 08:49 PM, Jürgen Weber wrote:
On Wed, Jan 4, 2012 at 11:59 AM, Florian Holeczek<flor...@holeczek.de> wrote:
Our community likes the 2.8 series for its stability and simplicity. Therefore,
maintaining the 2.8 branch at least for a longer while is something that really
makes sense.
2.8 is great. It's a reliable work-horse. I like the file based storage.
Why not take the radical step, throw the 3.0 branch away, go on with
2.8 and make it Apache-ready? I never understood, why a wiki, where
the wiki engine does the gui, would need a web framework. It should
suffice to refactor 2.8 to use a controller servlet.
And reread Joel Spolsky: Things You Should Never Do
http://www.joelonsoftware.com/articles/fog0000000069.html
8-) Juergen
Just my thoughts. 2.8 works great and waiting for 3.0
to work was very frustrating. Why not restart with 2.8
and let it involve to a better (3.0 like in the end?) system.
What might be done (with not too much effort):
- Provide a (better) interface for data storage
+ that allows for metadata (parent page ...)
+ that decouples the page name from the
capabilities of the file system (special
characters, upper/lower case, length)
A file based data storage should be the default
connection to that interface
(simple, easy to debug, no external dependencies,
the user has access to the data without problems).
What needs to be considered is under which
'identifier' (file name) a page should be stored.
The page name as it is used now can to trouble
('Main' and 'main' considered the same under
Windows, ...).
One solution would be a filtered, human
readable page name as a (natural) identifier
(just like the suboptimal one that is in use now -
xwiki by the way is nor happy at all if there is a
dot - '.' - in the page name).
Just an idea:
- a TimeUUID is used as (surrogate) identifier and its string
representation as file name (disadvantage: the
user has to search in the metadata for the page
name to find the file)
- the file itself is a serialised JSON that contains
metadata and contents - like:
{ "name":"Main", "author":"me", "contents":"bla bla" ... }
- there are many ways to represent history and
attachments with this scenario - not easy to find
'the right one'.
- Simplify things / remove unnecessary options
+ is there really a need for other character
sets as Unicode?
+ . . .
+ . . .
- Many developers have already (and seperately)
addressed some common needs - but nothing
has happend to 2.8 because all (including myself)
did wait for 3.0 to come (whose development was
too complex for me to follow):
+ Provide an option for simple installation
(on an USB stick).
+ Include attachments in the search algorithm.
+ Archives - a way to transfer pages and
attachments from one installation to another.
+ Search within attachments (TIKA)
+ . . .
All should be doable in small steps.
But i see two big problems:
- The 2.8 API is somewhat chaotic
(example: try to collect all source code
fragments that deal with the search
function).
Some refactoring in small steps might be
a (very) good idea but it would continuously
break the many private addones that have
been developed.
- Who shall decide what shall be done?
Janne like most of us does not seem to
have that much spare time.
A voting system? (an authorised developer
presents a relevant compatibility breaking
update and if after one week there are more
or equal '+1' than '-1' he can do what he wants).
Or GIT-like branching and the developers decide
every few months what should be merged to
the trunk?
I have no idea
(sorry for the long post)
Frank Fischer
