[rkward-devel] Fwd: Re: [JSS-Announce] Special issue on GUI's for R

[meik michalke]

[i believe this reply was supposed to reach the list as well :: m.eik]

----------  weitergeleitete nachricht  ----------

Betreff: Re: [rkward-devel] [JSS-Announce] Special issue on GUI's for R
Datum: Montag 05 Juli 2010 15:40
Von: "Stefan Rödiger" <stefan_roediger at gmx.de>
An: meik michalke <Meik.Michalke at uni-duesseldorf.de>


-------- Original-Nachricht --------
> Datum: Mon, 05 Jul 2010 15:10:30 +0200
> Von: meik michalke <Meik.Michalke at uni-duesseldorf.de>
> An: rkward-devel at lists.sourceforge.net
> Betreff: Re: [rkward-devel] [JSS-Announce] Special issue on GUI\'s for R

> hi stefan,
> 
> Am Montag, 5. Juli 2010, 13:51:35 schrieb Stefan Rödiger:
> > > for instance, we could reduce RKWards former dependency on PHP to 
> > > a footnote, restrict all mentioning of future ideas (and problems) to
> > > the discussion section and focus mainly the things RKWard does as of
> now.
> > 
> > The only trouble I have with the "future" is that nobody can predict
> what
> > it will be like.
> 
> i agree. actually i came up with this because you had some future
> statements 
> in your paper draft already (e.g., dealing with performance issues, lines 
> 89/90; inclusion of odfWeave, lines 233ff.) ;-)

Yes, you are right. This needs to be "fixed" somehow. Hopefully this supports 
how flawed claims in the paper might be if not backed by data. ;) . I just 
want to raise attention to this. odfWeave is a tricky example in my opinion. 
Based on the fact that R2THML is there in RKWard the "step to" odfWeave is 
"reasonable" though no code is there. I was working on odfWeave export but was 
never satisfied with my results therefore I never "published" it and put it on 
ice last year. One limitation for example was back than the plot export. I 
want the graphs conveniently editable (e.g. as SVG, ...) but this was to 
troublesome.

> 
> > Thus there is still a lot "we want to do this and that". Such claims
> need
> > support by data or another foundation. Everything else is vaporware.
> 
> you're right of course. although it wouldn't hurt to mention some planned 
> features that are likely to be implemented in the near future. say, if we 
> think back a little to when RKWard still relied on PHP, but the
> shortcomings 
> of it were already obvious, revealing the plans to probably replace it by 
> javascript wouldn't have been too deep a stare into the crystal ball.

True, we had Thomas working on it already and there were some results. Digging 
trough the list I realized how early he was starting to "fix" this. That's 
what I mean (and you already saw it the same way). 

> anyway, 
> my main point was that *if* future features are included, they should be 
> consequently moved/limited to the discussion section (for the ease of
> reading 
> and all the reasons you mentioned).
> 

yes, you are right. This is the right place for them.

> that is, i didn't want to nominate a new list of plans to be included, but
> suggest just a time dimension to apply to what we already have in the
> draft 
> for like a "defragmentation", if you will :-)

of course I didn't expect anything else :)

> 
> 
> viele grüße :: m.eik
> 


-------------------------------------------------------