> Your proposal looks awfully similar to Rob Loach's component system.
With some major differences.
First, the URL scheme (base path) is variable - which means you need
server-side code (or server-generated code provoding client-side
Also, this does more than just deliver assets - it explicitly
distinguishes CSS and JS from other assets, providing support for
serialization, which makes it an asset manager.
It also requires configuration, which would tie it (minimally) to a
specification, but more likely to an implementation. (or a
specification detailed enough that it's basically pseudo-code in
It's also based on the idea of explicitly packaging assets as separate
packages - whereas my proposal aims to allow for the inclusion of
assets into packages/projects. This means you have to set the package
"type" to "component" in your "composer.json" - which may force you in
some cases to package client and server-side dependencies separately,
which has implications in terms of dependency management, e.g. being
able to include my project's assets in the project, versus having to
version it as two separate packages and manage counter-breaking
changes between them, even for assets that are meaningless without the
server-side component, and vice-versa.
Rob's library looks nice. I aim for something simpler, that's all.
On Tue, Oct 18, 2016 at 10:08 AM, David Négrier <david.negr...@gmail.com> wrote:
> Hey Rasmus,
> Another thing came to my mind. Your proposal looks awfully similar to Rob
> Loach's component system.
> Have you had a look at it? => http://robloach.github.io/component-installer/
> Any thoughts about that? Shouldn't we consider building on this existing
> The difference is that Rob Loach has an implementation of a Composer
> installer instead. So rather than working on a specification, he directly
> created an implementation. Which is actually fine because you don't need a
> framework for your assets to be copied (they are copied/linked by the
> component-installer composer plugin that is a dependency of your asset
> What would be the value of an Asset-PSR (if you want to build a PSR out of
> it), instead of Rob's direct implementation?
> Best regards,
> Le lundi 17 octobre 2016 21:57:20 UTC+2, Rasmus Schultz a écrit :
>> A lot of people do a lot of things wrong. In my opinion, it's better to
>> create simple things that are easy to learn to use correctly - as opposed to
>> creating complex things that supposedly shield you from making mistakes.
>> Often such things provide only a false sense of security - and usually you
>> can break them and hurt yourself anyhow.
>> Most server side components have some kind of client side footprint - URLs
>> or HTML class names etc which can be used to figure out what you're running.
>> I really don't think it's within the scope of this specification to teach
>> OWASP 101? Package names are obviously revealed in the URLs - it's hardly a
>> hidden detail, it's basically the whole concept.
>> In my opinion, there is no security problem inherent in this idea, unless
>> you create one.
>> On Oct 17, 2016 9:30 PM, "Sven Sauleau" <sven.s...@gmail.com> wrote:
>>> Using this standard, people can know what packages you are using because
>>> of its predictable paths. Some packages are running server-side code as well
>>> as exposing public assets.
>>> I said (in the comments of the gist) that exposing stuff is the
>>> responsibility of the developer. I’m sure some people will be confused and
>>> disclose informations they shouldn’t (as mention by Fabien).
>>> Le lundi 17 octobre 2016 16:43:25 UTC+9, Rasmus Schultz a écrit :
>>>> I wrote a draft for a simple scheme for the inclusion of static assets
>>>> in (Composer) packages.
>>>> Not submitting this or anything, just dumping it here to start a
>>>> discussion :-)
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this topic, visit
>>> To unsubscribe from this group and all its topics, send an email to
>>> To post to this group, send email to php...@googlegroups.com.
>>> To view this discussion on the web visit
>>> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> To post to this group, send email to email@example.com.
> To view this discussion on the web visit
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.