<br><br><div class="gmail_quote">On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard <span dir="ltr"><<a href="mailto:matju@artengine.ca">matju@artengine.ca</a>></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 class="im">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 "int libpd_start_message(void)", which returns the current limit, and replace it with "int libpd_start_message(int length)", 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't compile with old versions of libpd AND vice-versa.<br></blockquote><br>Well, the vast majority of users won't notice any difference at all because they're using the Android or iOS branch, which I'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'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'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't be afraid to cut things that may turn out to be a burden in the long run. (That's why I floated the idea of getting rid of the simple message assembly mechanism, but it looks like that's here to stay.)<br>
Cheers,<br> Peter<br><br></div>