cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Enhancing serve
Date Thu, 14 Nov 2013 19:08:29 GMT
I like it all!

Exploring your plugin README's via serve  ==>  awesome.




On Thu, Nov 14, 2013 at 12:37 PM, Josh Soref <jsoref@blackberry.com> wrote:

> Braden wrote:
> > Generally speaking, adding new dependencies is fine,
> > so long as they aren't too extensive.
> > A markdown parser and friendlier JSON parsing are probably fine to add,
> > since they're not going to be adding five megs and a dozen transitive
> deps.
>
> I'll send a pull request for the JSON error reporting sometime soon.
>
> > Those changes look fine to me.
>
> > Do we have a use-case for exposing the $PROJECT/plugins directory?
>
> I don't have a strong use case.
>
> I'm coming from a perspective where I don't know anything about a project.
>
> The reason to expose the plugin list itself was because it seemed useful
> to know what was in the project. Then I wondered: what do these plugins do?
> And noticed that they had README files. So, mostly it's exposing the
> directory to expose the Readme files, which admittedly is fairly weak.
>
> Thinking about the markdown case, I'm going to change the flow a bit. The
> default served content should be raw files in case an application actually
> uses that format. The directory listing should include a query for markdown
> files indicating to serve that it should serve the HTML formatted version
> instead of raw.
>
> > That made me hesitate a bit,
> > though since serve is used for development I don't think it's a problem
> to be exposing them.
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message