On 26-02-18 17:06, IOhannes m zmölnig wrote:
hi all, TL;DR: i suggest a new deken fileformat to be ready for double-precision Pd (once it comes) and other future vagaries. it requires you to update the search plugin and (if you use them) the cmdline tools.
<snip> Read the long bit, sounds good.
# discussion for now i see two points that might require discussion. 1) katja suggested to use the arch-specific Pd-extensions (e.g. "d_ppc") instead of the more verbose "Darwin-ppc"). personally i'm not totally opposed, but i kind of like the verbose naming, as it allows for more future possibilities. e.g. "b_amd64" currently means "FreeBSD-amd64" but what about other BSD flavours, are they compatible? (not that i believe that most OSs apart from the current three will matter very much to the community in the near future; but then i'd rather be too inclusive than not)
As the package name is the main identifier of both package content and architecture, it is best to keep it more descriptive and verbose.
2) the proposed user-agent string might be considered a privacy issue. it currently is something like: "Deken/0.2.6 (Linux-amd64-32) Pd/0.48.1 Tcl/8.6.8" thus showing the Deken version, the Pd version the Tcl/Tk version and the architecture. note, that the current plugin uses Tcl/Tks default user-agent header, which already reveals the Tcl-version (and probably the OS, because different Tcl implementations seem to set the string differently). also, an architecture identifier is practically sent whenever your ordinary webbrowser sends a request to ...google or whatever. so i don't think that the header reveals problematic information, but then i thought it might be better to raise the awareness of others (you) first, before there are any complaints afterwards.
And as you normally only send it to a server you trust with providing you reliable binary, executable content, I don't see it as much of a problem.
3) having the server add an automatic search for "deken" if you are using an outdated version. the idea is, that if people who are using a plugin which cannot handle the new .dek file, they are nagged into upgrading deken. the only way the server can communicate to the plugin is via the search results. so why not add a search-result for a newer (compatible) version of deken whenever the user might need it (because they are missing search results which require a newer plugin). however, such "slight nags" can be pretty^Wvery annoying. i'd like to have feedback on this before i enable it.
Too bad the "popup/more info"-feature of the plugin hasn't happened yet. Is MacOS using a moodern Tcl/Tk version nowadays? It would give some more communication options.
that's probably it. fgmdasr IOhannes
Greetings, Fred Jan
[dek] https://github.com/pure-data/deken/tree/dek _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
