On 2010-08-23 17:17, IOhannes m zmoelnig wrote: > > now martin has already done this, but unfortunately i'm not very > satisfied yet. > probably i misunderstand something, but some things just don't work for > me (even in the help patch): >
and i already have one wishlist item: the 2 slip objects currently have a maximum slip package length of 1006 bytes. i know that rfc1055 mentions this maximum size, however: - the restriction is there to keep compatibility with a 1983 implementation... - it greatly reduces the useability e.g. it won't help for transmitting long OSC-messages (e.g. OSC bundles) for one thing, i don't think that [slipdec] should have a size restriction. usually such implementations should be conservative at the sender side, but liberal at the receiver side. (it probably would be nice if the user could clear the current decoding buffer without output - just in case...) i would also like, if [slipenc] would have a user-settable maximum size (of course, defaulting to 1006), so one could produce larger packages on demand. this is not high priority, as it is easy to repack a number of slip packages into a single one, but still... fgmasd IOhannes
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
