Re: [vqwiki-dev] Lexers and getting them more flexible

[Andreas S. <st...@gm...>]

Hello Martijn, Ryan

1. I think too it would be best just before a code freeze when nobody 
else can commit any changes.
2. The separate StyleSheet is as Martijn said a unique feature. So if 
you don't like it, I would like to see an option for that; default 
setting is StyleSheet as a topics as it is today. This keeps backward 
compatibility and gives the other option as you use it in your 
installation. Anyway, the including of the StyleSheet-Topic in the 
HTML-code is ugly. It would be better to have a servlet which will be 
simply used as stylesheet- URL-reference.
3. Yes too... ;-)

For the new lexer interface / abstract class I would also like to see 
enhancements in this area, but I would be happy if we *don't* include 
that in 2.7.8.
We have already alot of changes in 2.7.8 due to fixes in different areas 
and this change seems to me too big in a too short time. That's a bit 
risky. I think it would be better to be included in 2.7.9 or 2.8.

I agree with Ryan about the problems getting with rewrites. It's my 
experience too and I have also alot of discussions with developers in 
our commercial field because of that... always and again... (in fact I'm 
happy to hear from a developer that he also has this point of view ;-).
But just remember that this is an open source project maintained and 
programmed in our spare free time. So a complete rewrite is a 
possibility if this looks like fun. For me it would be also fun in 
helping rewrite vqwiki. ;-)

Cheers

Andreas

Martijn van der Kleijn wrote:

> Ryan,
>
> The new lexer will definitely NOT go in 2.7.8.... This would be quite 
> a big change and needs to be tested thoroughly, also to make sure we 
> don't break backward compatibility. In case this retains backward 
> compatibility for existing lexer or existing lexer can be easily 
> recoded to conform, we can consider this for an 2.8. version which is 
> not yet planned. Otherwise, this would perhaps be better placed in 3.0.
>
> For 2.7.8., I'd like you and Andreas to please focus effort on 
> squasing the existing bug reports in order of age, importance and 
> solvability. Also, since a lot of stuff happened this time around and 
> I've gotten several messages of our customers indicating their 
> positive feelings on the project, we need to thoroughly test 2.7.8 
> even before the code freeze. When the code freeze is in place, I will 
> get the most recent version from CVS, compile it and run an initial 
> test, update version info and tag it before building a release 
> package. Before doing so, I will determine which issues will be 
> deferred. The intention is to do NO coding between the freeze and 
> release except to correct release-blocking issues.
>
> As for your items:
>
> 1. Sounds good... but please be carefull since this will upset the 
> diffs it might make maintenance more difficult initially and I don't 
> want to be delayed. Maybe it would be best to put this off until we 
> are close to the code freeze.
>
> 2. The seperate style sheet... I can understand the attraction in it. 
> However, we've been getting very positive feedback on the StyleSheet 
> topic and have as such been trying to move away from a seperate style 
> sheet. What I WOULD like to see is the StyleSheet topic included as a 
> normal stylesheet instead of including the code. In the end, this 
> would simply mean that the StyleSheet topic is no more than a seperate 
> stylesheet editable as a topic.... I personally feel that it would be 
> a nice compromise between page download size and ease-of-use.
>
> What do think?
>
> 3. Yes.. :-)
>
> About 3.0... it is going to be a rewrite... please don't think this 
> decision was taken lightly. The reasons are many but are mainly as 
> follows:
> - VQWiki 2.7.x is not consistent in the way it handles actions and is 
> half way through a rewrite on that. For 3.x I want to introduce Spring 
> as a framework. This will increase flexibility, consistency and will 
> prevent us from re-inventing the wheel.
> - Introducing Spring would also allow us to improve templating for 
> VQWiki. Not for 3.0, but in a future 3.x release we could introduce 
> Velocity (or something similar) for example.
> - VQWiki 2.7.x has a serious problem with internationalization. It was 
> added as an afterthought and has proven to be unstable and inconsistent.
> - The plugin system as it is now is overly complex for end-users, not 
> entirely reliable and has a potentially severe impact on VQWiki 
> stability.
> - Filebased (and to lesser extent database-based) persistency is 
> inconsistent in places.
> - The current default Wiki ML is very inconsistent and not very 
> logical. This could be improved a lot.
> - Users have been requesting some sort of security system.
> - Users have been requesting topic meta data storage, which would also 
> be a pre-requisite for the above mentioned security system.
>
> All in all, I felt the project would benefit more from a complete 
> rewrite than incremental changes. That doesn't mean we throw out all 
> the old code, just that we start over from scratch and copy over 
> selected bits of code where applicable. We've learned, we've grown. 
> That coupled with the above items means we should not be afraid to 
> scrap and re-do it if that looks a valid option. As for 
> (in)compatibility: we're planning to provide a conversion tool so 
> end-users can easily convert their content/admin options to 3.x...  
> After all, major version upgrades should be allowed to be incompatible 
> with older versions at least a bit. :-)
>
> Where can you help? In order of importance:
>
> 1. Assist me and Andreas in bugfixing (I must admit that I don't find 
> bugs as quickly as Andreas ;-)
> 2. Test, test, test.... this has been lacking.
> 3. Work on the new lexer system as layed out in my previous mail
> 4. When I've moved CVS to Subversion and placed the initial 3.x code 
> in there: work on 3.x tasks I'll have available. (That goes for you 
> too Andreas)
>
> Lastly... I get the distinct impression that VQWiki as a project will 
> benefit a lot from both you and Andreas Studer. You both seem to be 
> professionals, good at what they do and willing to work towards a 
> common project goal whilst respecting your fellow team members.. I 
> hope you find me to be a competent project leader who is willing to 
> listen to your arguments and then make a decision for the project. 
> Should you or Andreas feel I can do better somewhere, please let me 
> know. My intent is to have us discuss things as a team, let us reach a 
> consensus and I'll finalize decisions for the project.
>
> Yours, Martijn
> -----
> VQWiki Project Lead
>
> Ryan Holliday schreef:
>
>> Hi Martijn,
>>
>> The new lexer proposal looks good.  If neither you nor Andreas want 
>> to implement it then I'll have time to put together some code early 
>> next week, although I don't think this should necessarily be a 2.78 
>> thing.
>>
>> Speaking of which, what are your plans for the 2.78 release?  I see 
>> from developer.vqwiki.org that you're planning a code freeze on April 
>> 24, so what else would you accept before then?  Some items I've got 
>> ready that could go in:
>>
>> 1. VQW-73 is an issue I've opened to standardize the VQWiki coding 
>> style.
>> 2. I've got a change in my local repository to allow the use of a 
>> stylesheet instead of an editable topic - the advantage of this 
>> approach is that it's easier to maintain over multiple installs, I 
>> prefer to maintain style as a CSS stylesheet, and it makes the page 
>> downloads smaller since the style information isn't included on every 
>> page.
>> 3. Several code cleanups.  Action values are hard-coded in a number 
>> of places, there are several instances of loggers using the 
>> deprecated "Category" logger instead of the "Logger" logger, etc.  
>> Can those be implemented?
>>
>> My understanding is that after the 2.78 release you're planning on 
>> migrating to Subversion and then beginning 3.0.  I've seen some 
>> comments referencing this change being a complete rewrite, but it 
>> might be better to make it a more incremental release unless there is 
>> a pressing need to start over - my experience with rewrites has been 
>> that unless something is totally broken, it's often better to make 
>> small changes rather than create an entirely new (and often 
>> incompatible) product.
>>
>> Please let me know your thoughts, what I can do to help, and if any 
>> other code would be accepted.  I'm visiting my family for the Easter 
>> holiday this weekend, but will be available again next week and until 
>> early May, after which I'm gone again for a couple of weeks.
>>
>> Cheers,
>>
>> Ryan
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> veryquickwiki-develop mailing list
>> ver...@li...
>> https://lists.sourceforge.net/lists/listinfo/veryquickwiki-develop
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> veryquickwiki-develop mailing list
> ver...@li...
> https://lists.sourceforge.net/lists/listinfo/veryquickwiki-develop
>
>