[PD] sending image from of / libpd

Peter Brinkmann peter.brinkmann at googlemail.com
Wed Aug 31 14:45:35 CEST 2011


On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox <danomatika at gmail.com> wrote:

> 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.
>

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's easy to fix.  The language bindings for Java and Objective-C
actually became simpler when I updated them for the new version.

I don'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's the tiny extra effort of passing in
the limit every time you start a message, or you don't have an a-priori
limit, in which case you need to check the length before assembling a
message anyway.

Another aspect is API design.  One feature of a good API is that it'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.
Cheers,
     Peter



>
> On Aug 30, 2011, at 5:47 PM, Peter Brinkmann wrote:
>
>
>
> On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard <matju at 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110831/00e31d75/attachment.htm>


More information about the Pd-list mailing list