<br>On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox <span dir="ltr">&lt;<a href="mailto:danomatika@gmail.com">danomatika@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">I think it&#39;s much simpler to just add a call to get/set the message limit, say:<div><br></div><div>int libpd_max_message_length();</div><div>void libpd_set_max_message_length(int length);</div>
<div><br></div><div>This doesn&#39;t break any current code.</div><div><br></div><div>Having to set a custom limit each time is far more tedious then just setting it at startup.</div></div></blockquote><div><br>Actually, breakage of current code is a feature as far as I am concerned because it makes people aware of the change, and it should be harmless because it&#39;s easy to fix.  The language bindings for Java and Objective-C actually became simpler when I updated them for the new version.<br>
<br>I don&#39;t think the new signature of libpd_start_message is tedious, really.  Essentially, I see two use cases: Either you know an a-priori limit on your message length, in which case there&#39;s the tiny extra effort of passing in the limit every time you start a message, or you don&#39;t have an a-priori limit, in which case you need to check the length before assembling a message anyway.<br>
<br>Another aspect is API design.  One feature of a good API is that it&#39;s difficult to use incorrectly.  With a separate call for setting the message limit, people will forget that the limit is a consideration.  With the current solution, people will briefly contemplate the length of each message they start, which is a good thing.<br>
Cheers,<br>     Peter<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div><div></div>
<div class="h5"><br><div><div>On Aug 30, 2011, at 5:47 PM, Peter Brinkmann wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard <span dir="ltr">&lt;<a href="mailto:matju@artengine.ca" target="_blank">matju@artengine.ca</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>On Tue, 30 Aug 2011, Peter Brinkmann wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
For the time being, I have something much simpler in mind: Just take the current call &quot;int libpd_start_message(void)&quot;, which returns the current limit, and replace it with &quot;int libpd_start_message(int length)&quot;, which takes a parameter indicating the length of the message and returns a nonzero error code if the length is too big.<br>


</blockquote>
<br></div>
But this means that new libpd-using apps won&#39;t compile with old versions of libpd AND vice-versa.<br></blockquote><br>Well, the vast majority of users won&#39;t notice any difference at all because they&#39;re using the Android or iOS branch, which I&#39;m updating as I go along.  The only people who are affected by this are those who are using the C library directly, and I hope that they&#39;ll either be willing to update their code (which should be no more than a two-line change in most cases) or just stick to the current version, which will remain available via git.<br>

<br>
In any case, I think everybody understands that this is still a young library that 
needs to adapt as we gain a better understanding of how people
 are using it, and the cost of making a small incompatible change is a lot lower than choosing a suboptimal solution for compatibility with an earlier version.  This period of youthful innocence is coming to an end, though; the API has been quite stable for quite a while now, and I believe that it&#39;ll soon be time to declare it finished.  I want to take a critical look at every piece before we officially lock the API, and I won&#39;t be afraid to cut things that may turn out to be a burden in the long run.  (That&#39;s why I floated the idea of getting rid of the simple message assembly mechanism, but it looks like that&#39;s here to stay.)<br>

Cheers,<br>     Peter<br><br></div>
</blockquote></div><br></div></div><div class="im"><div>
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div>--------</div><div>Dan Wilcox</div><div><a href="http://danomatika.com" target="_blank">danomatika.com</a></div><div><a href="http://robotcowboy.com" target="_blank">robotcowboy.com</a></div><div><br></div></div></span><br>
</span><br>
</div>
<br></div></div></div></blockquote></div><br>