Hi -
> Welcome back!
Thanks!
> > At this time, there appears to exist
> > no widespread UNIXy infrastructure to package web application
> > artifacts as reusable elements, so there's no way to link to a
> > "system" copy of these.
>
> Hmmm, "no way"? How about creating packages for them, like the
> http://fedoraproject.org/wiki/Changes/jQuery project.
This model is quite new and narrowspread.
> As discussed elsewhere before your vacation, I'm not comfortable
> adding copies of 100s of 1000s of lines of javascript code and
> images to core PCP from projects that we didn't author, nor have
> plans/skills to maintain ourselves.
I'm not comfortable either, but solutions that make everyone
comfortable are not likely to exist soon.
> > [...]
> > With respect to libmicrohttpd, I am not keen on pursuing this
> > embedding approach, and as outlined above, the web application
> > artifacts are only reluctantly embedded. No "keen pursuit" here.
>
> Oh, I was thinking of the recent thread where you wrote:
>
> " [...] perhaps a better solution would be to arrange to
> include a bundled copy of libmicrohttpd along the pcp tarball, and
> build/link them together. (I recall at one point, the code base
> -did- have a bundled libmicrohttpd for just such reasons.)"
> [ http://www.pcp.io/pipermail/pcp/2014-July/005248.html ]
A closer reading of this tentatively suggests "embedding"
libmicrohttpd by not embedding it in the pcp source tarball at all,
but shipping it alongside within distro-packages that support that -
.src.rpm's do, not sure about .deb's). src.tar-based pcp users would
be SOL for example.
Would your discomfort be eased if this same non-embedding embedding
were experimented with for purposes of the web applications? Namely,
include src tarballs of graphite/grafana/etc. within pcp src.rpm's,
and have these be untarred under /usr/share/pcp/jsdemos during the
build/install phase?
- FChE
|