No subject

<br>&gt; create another &quot;language&quot;?<br><br>Because that other language would be more integrated with pd itself and<br>integration is good, if it really makes things feel more familiar. You can<br>witness the importance of this by looking at how much people avoid using
<br>other programming languages with pd (beyond the difficulties in compiling<br>externals and distributing patches that use code like that).</blockquote><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder">
</div><div>My comment here was in creating the SQL statement. I was hoping not to create a version of SQL that was specific to PD, that is what I meant by a waste of time.&nbsp;</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
The big downside of integration is that it usually does not cover the<br>whole feature set of what is being wrapped, and especially not nonstandard<br>extensions.</blockquote><div><br class="webkit-block-placeholder"></div>
<div><br class="webkit-block-placeholder"></div><div>And then you add to this the differences between different databases. While I hope to be able to swap one database for another, I don&#39;t know if it would be possible to do that without having to tweak the SQL statements that were created.&nbsp;
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; At the same time, should our external be on the look out for these sorts<br>&gt; of things? One of the original ideas was to not give the external any,
<br>&gt; if at all, knowledge of SQL. Meaning, it wouldn&#39;t &quot;parse&quot; the SQL, nor<br>&gt; would it try to do any generation of SQL. It just expects that the user<br>&gt; is HONEST (that is what these concerns over Injection are, right), and
<br>&gt; the SQL they entered is what they meant.<br><br>You can&#39;t assume that the user is honest, because when you do, you also<br>assume that the user does not make mistakes when including input from<br>other sources that can&#39;t be assumed to be honest.
</blockquote><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>Well, this is one of those reasons why I am starting with using SQLite, I think it would be much easier than working with a networked database. And if someone is being &#39;dishonest&#39;, then they are only effecting themselves.
</div><div>&nbsp;</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; While we can try to protect against various things, those that want to<br>&gt; be malicious will do so anyway.
<br><br>This is not true. Every step is important in making it more difficult for<br>abuse to happen.</blockquote><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>Well, if we are allowing these people to construct their own SQL and they are building their own stuff, just how can we stop them from being malicious? I mean, the only real way to stop this completely, is to not produce a network version of this, and only deal with standalone.
</div><div><br>&nbsp;</div><div>Mike</div><div><br class="webkit-block-placeholder"></div></div>

------=_Part_1541_20067193.1198271380458--