[PD-dev] deken: major revamp of the packaging format for externals

[Fred Jan Kraan]

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
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>