I think it's much simpler to just add a call to get/set the message limit, say:
int libpd_max_message_length(); void libpd_set_max_message_length(int length); This doesn't break any current code. Having to set a custom limit each time is far more tedious then just setting it at startup. On Aug 30, 2011, at 5:47 PM, Peter Brinkmann wrote: > > > On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard <ma...@artengine.ca> wrote: > On Tue, 30 Aug 2011, Peter Brinkmann wrote: > > 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. > > But this means that new libpd-using apps won't compile with old versions of > libpd AND vice-versa. > > 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. > > 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.) > Cheers, > Peter > -------- Dan Wilcox danomatika.com robotcowboy.com
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
