[dokuwiki] Re: [GSoC] Introduction and some ideas
- From: Michael Hamann <michael@xxxxxxxxxxxxxxxx>
- To: dokuwiki <dokuwiki@xxxxxxxxxxxxx>
- Date: Tue, 29 Mar 2011 22:46:59 +0200
Hi Constantinos,
Excerpts from Constantinos Xanthopoulos's message of 2011-03-28 15:20:02 +0200:
> As a user of DokuWiki and I would like to congratulate you for
> your submission to GSoC!
> I am pretty confident that after this summer DW will be even better!
Thanks!
> All the proposed ideas are great, thought the ones I would like to
> work with are: pagemoveng which is essential and merge.
>
> ** pagemoveng **
>
> Pagemoveng is, in my opinion, an extremely important function missing from DW.
> This fact motivates me even more to help in its development!
> I have already got into plugin [1] development for DW and I believe that
> by developing pagemoveng I will manage to fully comprehend the way DW
> works.
> Regarding the implementation, thread [2] covers this issue in many
> ways, ways I would be glad to discuss via IRC
Okay, I'm online now, but perhaps discussing that here would also be a
good idea, as then more people will be involved.
> ** Merge **
>
> The idea of merging from the first moment I took a glimpse of it in a
> RCS intrigued me, and I would like to implement it in DW.
> A pure PHP implementation for merging and JS for notification messages
> (probably with AJAX) would be perfect. Firstly, I would try to
> implement my 3-way merging class (this would help me learn) and if the
> benchmarks are poor I would continue by using one of the libraries
> suggested.
What exactly do you want to gain by implementing your own merge
implementation instead of using an existing (and hopefully) working one
apart from experience? Of what notifications are thinking? And keep in
mind that merging needs to work without JavaScript.
> In addition, here are some ideas I would like to recomment that will
> help the further evolution of DW.
>
> Create a class which will give the option of reading and saving data
> from DW covering the following features:
>
> 1. Independent from PHP libraries in order to achieve high level of
> compatibility.
> 2. Caching functions where needed in order to obtain faster reading of
> data which do not alter frequently.
> 3. Benchmarking the class with the other known techniques of saving
> based on files (JSON, sqlite, etc) in order to optimize the access
> time.
> If we manage to implement all of the above it would be useful to adapt
> it with the current configuration system.
I don't think it will be possible to implement something that's better
than the builtin serialize. When we've talked about the metadata system
and wondered if using something like JSON would be better because it's
human readable and supported by more programming languages etc. I did
some little benchmarks in order to see what's faster, you can find it at
https://github.com/michitux/dokuwiki-test-serialize, as you can see in
results.txt at least from my tests serialize seems to be the fastest.
From that pure PHP JSON implementation you can also see that something
written in PHP will most probably be a lot slower than the builtin
functionality. And I don't think we need an additional wrapper for
calling serialize + ioSaveFile.
> To be punctual, during the period of June I will have to parallely
> face my university exams (for 4-5 courses) so I will no be as much
> available as needed but I am more than eager and I will give my best
> to fill the missing hours the next (or even previous) weeks!
I think if you'll be able to start coding during the community bonding
period that should work.
Michael
--
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist
Other related posts:
