[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_roedi...@gmx.de> An: meik michalke <meik.micha...@uni-duesseldorf.de> -------- Original-Nachricht -------- > Datum: Mon, 05 Jul 2010 15:10:30 +0200 > Von: meik michalke <meik.micha...@uni-duesseldorf.de> > An: rkward-devel@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 > ------------------------------------------------------- ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
