Ugh I didn’t say that :( What I said with more emphasis: Not because of all its features, (because I agree Puli is very complex)
but because it contains a very simple solution to a wider problem: locating resources. (“contains” ≠ “is”) You want to standardize a assets/ directory, I’m suggesting to standardize the res/ directory instead (which would contain assets). And it’s not more complex, I would argue it’s even simpler because instead of creating discrepancies between different resources (assets, templates, config…) it would all have the same behavior. The problem is, I don’t have any of those requirements - so it solves a bunch of problems that I don’t have. What people do with assets is a real question. Either the PSR addresses the major use cases, or it avoids addressing any (both solutions are good but the last one is obviously simpler). Matthieu Le 18 octobre 2016 à 16:16:29, Rasmus Schultz (ras...@mindplay.dk) a écrit: > I was going to mention Puli too. Not because of all its features, but because > it contains a very simple solution to a wider problem: locating resources. If you think Puli is simple, we can agree to disagree. I make a sharp distinction between simple and easy - Puli aims to make dependency management easy, but doing everything Puli does for assets requires a complex system. It's not simple. Don't get me wrong - the complexity in Puli is justified for all the tasks it makes easy: mapping, locating, publishing, minifying, serializing, etc. The problem is, I don't have any of those requirements - so it solves a bunch of problems that I don't have. > your proposition only solves how to expose them, which is quite restrictive >From your point of view, this is restrictive, because you have all of those requirements. >From my point of view, it's liberating, because I have none of those requirements. Or rather, I choose to address them at a different level - I don't view tasks such as compiling, minifying, serializing, etc. as run-time tasks at all. I view them strictly as design-time tasks - I perform those tasks ahead of run-time, and ship the ready, published, minified, serialized assets as pre-baked static files that I check into source-control. There is also the case where scripts receive no design-time processing and are simply hand-written and checked in. For that scenario, having any sort of run-time overhead or server-side complexity is completely meaningless. Standardizing for the simple case is simple. If you wanted to standardize the far more complex case, that's going to require an entirely different, far more complex standard. On Tue, Oct 18, 2016 at 10:51 AM, Matthieu Napoli <matth...@mnapoli.fr> wrote: > Hi Rasmus, > > I was going to mention Puli too. Not because of all its features, but > because it contains a very simple solution to a wider problem: locating > resources. > > Puli encourages to have a `res/` directory containing all resource files > (just like `src/` contains all source files). Resources include assets, > configs, templates, etc. Because the problem with everything that is not a > source file is "how to locate it" (for source files we have the autoloader). > > Once an application can locate assets, it can publish them, minify them, > etc. The standard would avoid deciding what to do with assets (whereas your > proposition only solves how to expose them, which is quite restrictive). The > less the standard expects the better. > > Matthieu > > > Le mardi 18 octobre 2016 10:08:56 UTC+2, David Négrier a écrit : >> >> 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 >> example? >> >> 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 >> package). >> 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, >> David. >> >> >> 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. >>>>> >>>>> https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee >>>>> >>>>> Not submitting this or anything, just dumping it here to start a >>>>> discussion :-) >>>>> >>>>> Thoughts? >>>>> >>>> -- >>>> 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 >>>> https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> php-fig+u...@googlegroups.com. >>>> To post to this group, send email to php...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/php-fig/c2ba50bb-ad74-4675-8ccd-08cdd8a360a0%40googlegroups.com. >>>> >>>> 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 > https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/e4f0f008-ab9f-4592-8d6e-edab03812447%40googlegroups.com. > > > 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 https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe. To unsubscribe from this group and all its topics, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_jMYt_fM7Fk2JbFYwTsf%2B6LJR-0ykmwKi9gnCXjWT2A5g%40mail.gmail.com. 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/etPan.58063280.368a0287.82bd%40mnapoli.fr. For more options, visit https://groups.google.com/d/optout.
