<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 January 2016 at 04:50, David Narvaez <span dir="ltr"><<a href="mailto:david.narvaez@computer.org" target="_blank">david.narvaez@computer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>> wrote:<br>
> Short answer, not many commits for that, even dedicated maintainer probably<br>
> welcome, no special interest resulting in real coding, and especially,<br>
> organized design.<br>
><br>
> Longer answer require showing more context.<br>
><br>
> I can first mention atmosphere around Python and scripting in general closer<br>
> to the Kexi circles.<br>
><br>
> But I believe since the intent is to have consistent scripting in the<br>
> future, it somehow helps to see some relation to Sheets, being in the same<br>
> class of apps.<br>
><br>
> As some people may know I like Python for its purposes. KDE even started (in<br>
> Calligra) projects such as Kross to support more languages honestly. This<br>
> support was were means for not too deep bindings, not language-specific,<br>
> rather calling methods of objects without much regard to integration with<br>
> data types or language specifics.<br>
><br>
> As a part of general 'cleanup' Kexi 3 removes Kross usage and moves towards<br>
> a single language-solution that happens to be JavaScript, using QtQml. The<br>
> main reason is that sandbox works there and not in Python.[1] By default<br>
> QtQml gives no tiny chance to access filesystem for example or run unwanted<br>
> scripts.<br>
><br>
> There are no declared lovers of JavaScript among us, C++ hackers I think.<br>
> But the specifics of JavaScript is less of a problem than inherent<br>
> insecurity of Python's execution environment. Insecurity would manifest once<br>
> apps that use scripts get popular. The result I'd expect is very much like<br>
> perfect cross-platforms viruses.<br>
> This is possible if scripts are accessible with documents, which is<br>
> assumption of Kexi (files are meant to be user-defined apps) and in the<br>
> future, I believe, also Sheet's documents, if we want competitiveness.<br>
><br>
> For that matter, also ruby and bash and perl, would be all better rejected<br>
> for the same reason.<br>
> Sure, there were ideas of digital signing of scripts but 1. Even tech people<br>
> do not use that (and even for emails) in general, 2. Except for Krita<br>
> "official" builds we're not controlling the deployment process, distros do<br>
> that, and I imagine all sort of critical issues can sooner happen e.g.<br>
> because of mixes responsibility. It seems that distros are able to act more<br>
> "reactionary", not as "owners" of the software as a product. Which does not<br>
> surprise me and there's nothing to criticize.<br>
><br>
> For Kexi <=2 (no matter what language is picked) scripting is marked as<br>
> having experimental status. I am not sure whether this is the case for<br>
> Sheets too but for Kexi there's because of such honest status we can assume<br>
> there's no disservice to users. With Kexi 3 we have ability to start fresh<br>
> and with knowledge/experience gathered in the past. Also about knowledge<br>
> about the user base.<br>
><br>
> For some other contexts the choice scripting can depend on external<br>
> requirements. Like "industry" standards -- for Krita Python is perceived as<br>
> some kind of standard for extending graphical features. Similar opinion<br>
> applies for Krita itself - generic calligra-wide scripting never have been<br>
> too actively maintained and was Kross is too simple, see [2]. For the<br>
> record, Krita has a proof-of-concept implementation of scripting in a<br>
> separate repo.<br>
><br>
> [1] Google for "Python sandbox" for detailed discussion from Python hackers<br>
> on why this is not possible and dropped idea.<br>
> [2] <a href="https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html</a><br>
<br>
</div></div>Ditching Python because of sandboxing issues makes sense. That being<br>
said, I would use Python to access the file system from my<br>
spreadsheets all the time. I don't really remember what made me to<br>
look into scripting support in Sheets but I vaguely remember something<br>
merging several CSVs into a single spreadsheet.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Yes, data integration is one of the most useful use cases.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In any case, if the current plan is to remove Python support, I guess<br>
I am better off working on removing that instead of fixing it,<br>
correct?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I give no definitive </div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">answer here stating that common organized approach in Calligra is a valuable thing. Especially that resources are always limited and better to have one effort than multiple. Sheets maintainer decides for Sheets and it can be assumed that who codes largely decides too. <br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Assuming that removal of unused/unmaintained code will be decided, yes it's better to drop such things from Calligra 3 codebase, than just disabling the build. The code will still sit in the history anyway. After agreement feel free to submit patches to Phabricator Calligra.git repo and/or tasks for Calligra 3.0 Phabricator's project. <br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">PS: I would be interested in understanding how more or less you perform the integration/access the filesystem: do you implement routines to read custom file formats or so? I am collecting such information for Kexi 3 scripting features.<br></div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
David E. Narvaez<br>
<div class=""><div class="h5">_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>