Il giorno mercoledì 2 maggio 2018 19:23:59 UTC+2, Manlio Perillo ha scritto:
>
> Il giorno mercoledì 2 maggio 2018 17:51:24 UTC+2, Robert Johnstone ha
> scritto:
>>
>> Before there was a wide range of tools for embedding assets, I wrote my
>> own. It is relatively complete, but it did not have a feature to create a
>> debug mode for assets. However, the server took a command-line flag for
>> debug mode, and would access assets through the file system instead of the
>> embedded data.
>>
>> The point being, the "standard" tool would not have to support
>> everything, it could be a building block for other packages. The key
>> functionality would be embedding possibly large assets into the linked
>> executable. I haven't measured in a while, but embedding assets did have a
>> significant impact on build times. Finding the most efficient technique
>> would be a usable block, all on its own. Additional conveniences could be
>> built on top.
>>
>> Robert
>>
>>
>
> Beside a "standard" tool, maybe we need a "standard" interface; e.g.
> package data
>
>
> type Asset interface {
> Load(path string) (io.Reader, error)
> }
>
>
Sorry, there is an error.
It should be
type Asset interface {
// Open opens the asset of the specified package at the specified
path.
//
// pkg must be the full import path of the package. path must be a
relative
// path.
Open(pkg, path string) (io.Reader, error)
}
> and have some default implementations.
>
> Assets can be stored in several place, like
> - Global system path (/usr/share)
> - Local system path (/usr/local/share)
> - User path (~/.local/share)
> - A Custom path
> - Embedded in the executable
>
>
And, of course, can be also be stored in the package source code directory.
Manlio
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
