cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Heifetz <jheif...@blackberry.com>
Subject Re: Non-Git Plugin Dependencies
Date Mon, 09 Sep 2013 16:05:35 GMT
So it seems I killed all discussion here, but before I did that I feel we
reached a consensus that relative dependencies are something we'd like to
support. The final decision to make is how we would like to do so.

Current Implementation <dependency id url commit subdir />. When url = "."
then the dependency is treated as living in a git repo and the path is
<gitRoot>/subdir

Proposal 1:
When url is missing entirely then the dependency is treated as file-system
relative and the the path is <current plugin.xml>/subdir

Proposal #2 We update the dependency element to <dependency
src=url#branch:subdir>. If you want a git relative path then url = "." and
for file-system relative url != "." and does not have "://"

Does this seem correct to everyone? Does anyone have any strong opinions
one way or the other?


On 13-09-04 4:18 PM, "Jeffrey Heifetz" <jheifetz@blackberry.com> wrote:

>While I believe we could be able to specify everything with a single
>parameter, I don't follow what problem we're trying to solve by doing so.
>
>If I understand everything correctly we're comparing the following;
>   <dependency src=url#branch:subdir />
>   <dependency url=url commit=branch subdir=subdir />
>
>While both seem reasonable and I do like the first, this seems
>unnecessary.
>
>On 13-09-04 3:18 PM, "Braden Shepherdson" <braden@chromium.org> wrote:
>
>>Not quite, since the checked-out directories generally don't have the
>>".git" suffix; you'd have to override git's normal naming behavior when
>>cloning these.
>>
>>I think that's quite a bit of delicate magic we don't need. I think src
>>might be a better name, if we wanted to go with a single parameter.
>>
>>If we want to go with two, I like url and path. Supplying both and
>>choosing
>>based on where the parent plugin was fetched from, that would probably
>>work.
>>
>>I think src="" and my three use cases above works. Thoughts?
>>
>>Braden
>>
>>
>>On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <agrieve@chromium.org>
>>wrote:
>>
>>> Here's another use-case:
>>> - You have a github account
>>> - You have one plugin per repo
>>> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
>>> - You want AppBundle to depend on
>>> https://github.com/MobileChromeApps/zip.git
>>> - You want this to work when you've got your plugins checked out for
>>>local
>>> dev:
>>> plugins/AppBundle.git
>>> plugins/zip.git
>>>
>>> You try <dependency src="zip.git" />
>>>
>>> If we treated this as a relative URL, then it would actually work in
>>>both
>>> cases (online or checked out). If we treat non-absolute-urls as
>>>subdirs,
>>> then things don't work out for this use-case. If we use path= for
>>>subdirs
>>> and url= for repo URLs, then both use-cases work out.
>>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mmocny@chromium.org>
>>>wrote:
>>>
>>>> I'm not convinced that all use cases cannot be handled with a single
>>>> attribute.  Maybe url / path are the wrong names, maybe a single
>>>>src="".
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson
>>>><braden@chromium.org>wrote:
>>>>
>>>>> Sure, I can work with path="" instead. What happens if (when) a user
>>>>> supplies both?
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve
>>>>><agrieve@chromium.org>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
>>>>>> braden@chromium.org> wrote:
>>>>>>
>>>>>>> I believe the current logic is "a plugin with this ID is already
>>>>>>> installed, so stop". That interacts badly with different versions.
>>>>>>>
>>>>>>> Braden
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny
>>>>>>><mmocny@chromium.org>wrote:
>>>>>>>
>>>>>>>> .. but either way if we add support for filesystem-relative
paths
>>>>>>>>and
>>>>>>>> they work when fetching the original plugin either from git
or
>>>>>>>>locally,
>>>>>>>> then we are done.
>>>>>>>>
>>>>>>>> As an aside, when a plugin lists its dependency as explicitly
from
>>>>>>>>a
>>>>>>>> git url, can the user somehow override that to install from
a
>>>>>>>>local copy?
>>>>>>>>  Perhaps if they manually install the dependant first, then
we
>>>>>>>>won't go
>>>>>>>> fetch from git needlessly?  How does that interact with different
>>>>>>>>versions
>>>>>>>> of the plugin?
>>>>>>>>
>>>>>>>> -Michal
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny
>>>>>>>><mmocny@chromium.org>wrote:
>>>>>>>>
>>>>>>>>> Jeffrey's point at the start of this thread is that he
isn't
>>>>>>>>>using a
>>>>>>>>> git repo locally, so there is no .git folder to find.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>>>>>> braden@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> I like where this is generally going, but I want
to correct one
>>>>>>>>>> mistake Michal made. There /is/ a way to know which
directory
>>>>>>>>>>above a
>>>>>>>>>> plugin is the root. The code uses git to find the
.git
>>>>>>>>>>directory, which is
>>>>>>>>>> taken to be the root from which the subdir is relative.
That
>>>>>>>>>>means that in
>>>>>>>>>> the case of url="." and url="https://github.com/..."
the subdir
>>>>>>>>>> has the same meaning: relative to the git root.
>>>>>>>>>>
>>>>>>>>>> I like the path="" option. I agree that subdir and
ref could be
>>>>>>>>>> dropped, since they can be specified as part of the
URL. On the
>>>>>>>>>>other hand,
>>>>>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>>>>>
>>>>>>>>>> I suggest:
>>>>>>>>>>
>>>>>>>>>> 1. Remote git, all in URL: url="
>>>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>>>>>  2. Remote git, separate parameters: url="
>>>>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir"
>>>>>>>>>>ref="somebranch"
>>>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>>>>>> ref="somebranch"      (we can probably support all-in-URL
here
>>>>>>>>>>too)
>>>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"
     (no
>>>>>>>>>> all-in-URL here; there's no need for the other parameters
in
>>>>>>>>>>this case)
>>>>>>>>>>
>>>>>>>>>> The last can be differentiated from the others easily
enough,
>>>>>>>>>>the
>>>>>>>>>> logic is:
>>>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0)
If so, it's a
>>>>>>>>>> remote git. This is already supported fully.
>>>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative
path.
>>>>>>>>>> Already fully supported.
>>>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and
so the new
>>>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin,
>>>>>>>>>> dep.attrib.url); Though some path-separator tweaking
is always
>>>>>>>>>>required.
>>>>>>>>>>
>>>>>>>>> I think this will be confusing. For case #3, you have
the "url"
>>>>>> attribute that defines the path, and not the url. I would look at
>>>>>>this and
>>>>>> interpret it as a relative URL, and the URL is meant to tell you
>>>>>>where the
>>>>>> git repo is. It would be much clearer to call this "path" instead
of
>>>>>>"url"
>>>>>> for #3 I think.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>> (Re: paths, all paths in plugin.xml should be specified
to use /
>>>>>>>>>> always, URLs and filesystem paths both. It's the
tool's job to
>>>>>>>>>>properly
>>>>>>>>>> split and convert to Windows backslashes where appropriate.
I'm
>>>>>>>>>>sure there
>>>>>>>>>> are a few places where we've gotten this wrong; Windows
users
>>>>>>>>>>please file
>>>>>>>>>> bugs if you run into them. Mostly, though, I was
careful to
>>>>>>>>>>split/join
>>>>>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>>>>>
>>>>>>>>>> Thoughts on that proposal?
>>>>>>>>>>
>>>>>>>>>> Braden
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny
>>>>>>>>>><mmocny@chromium.org>wrote:
>>>>>>>>>>
>>>>>>>>>>> For now, yes, but we could extend that without
breaking
>>>>>>>>>>>anything,
>>>>>>>>>>> no?
>>>>>>>>>>>  Right now url="../etc" would be invalid, so
we could safely
>>>>>>>>>>>add
>>>>>>>>>>> support
>>>>>>>>>>> for urls with leading "..", and make that relative
to current
>>>>>>>>>>> plugin.
>>>>>>>>>>>
>>>>>>>>>>> url="." would still do what it does today, but
could likely be
>>>>>>>>>>> deprecated
>>>>>>>>>>> along with subdir and commit attributes (or at
least document
>>>>>>>>>>>the
>>>>>>>>>>> limitation of that approach somewhere).
>>>>>>>>>>>
>>>>>>>>>>> Not sure about making the form url="./etc" be
relative to URL
>>>>>>>>>>>root
>>>>>>>>>>> or
>>>>>>>>>>> current plugin, but I don't see why that form
would ever be
>>>>>>>>>>>useful
>>>>>>>>>>> anyway.
>>>>>>>>>>>
>>>>>>>>>>> -Michal
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve
<
>>>>>>>>>>> agrieve@chromium.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> > Because for the hosted case, the URL points
to where the repo
>>>>>>>>>>> is, not to
>>>>>>>>>>> > where the plugin is.
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal
Mocny <
>>>>>>>>>>> mmocny@chromium.org> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> >> If URL can be relative, why do we need
a new path parameter?
>>>>>>>>>>>  All we
>>>>>>>>>>> >> would need is to treat leading ./ or
../ as relative to the
>>>>>>>>>>> plugin not
>>>>>>>>>>> >> root, which I think is fine.
>>>>>>>>>>> >>
>>>>>>>>>>> >> I'll sleep on it and draw it out on
whiteboard tomorrow to
>>>>>>>>>>>make
>>>>>>>>>>> sure all
>>>>>>>>>>> >> the cases are handled.
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew
Grieve <
>>>>>>>>>>> agrieve@chromium.org>wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >>> Agree the use-case is valid. Here's
a variation on (1) that
>>>>>>>>>>>I
>>>>>>>>>>> think is
>>>>>>>>>>> >>> marginally nicer:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> url="." to be made optional, but
default value is "."
>>>>>>>>>>> >>> subdir="" works only with git repos
and is always relative
>>>>>>>>>>>to
>>>>>>>>>>> the root
>>>>>>>>>>> >>> of the repo.
>>>>>>>>>>> >>> path="" works with git repos or
local paths and is relative
>>>>>>>>>>>to
>>>>>>>>>>> the
>>>>>>>>>>> >>> plugin.xml of the current plugin.
You can't have "url" or
>>>>>>>>>>> "subdir" if you
>>>>>>>>>>> >>> have "path".
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Support was just added for specifying
commit and path
>>>>>>>>>>>within
>>>>>>>>>>> url. So, we
>>>>>>>>>>> >>> could actually just deprecate "subdir".
and have "url" or
>>>>>>>>>>> "path"
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> E.g.: url="some/path.git" would
specify a git URL relative
>>>>>>>>>>>to
>>>>>>>>>>> the
>>>>>>>>>>> >>> current plugin's git url.
>>>>>>>>>>> >>> E.g.: url="#branch2" would specify
a branch on the current
>>>>>>>>>>>URL
>>>>>>>>>>> >>> (cordova-labs style)
>>>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would
specify a branch on
>>>>>>>>>>>the
>>>>>>>>>>> current URL
>>>>>>>>>>> >>> plus a subdir within it.
>>>>>>>>>>> >>> E.g.: url="#:plugins/A" would be
invalid. (Use path if you
>>>>>>>>>>> just want to
>>>>>>>>>>> >>> set the path)
>>>>>>>>>>> >>> E.g.: path="../B" is always a relative
fs path. If the
>>>>>>>>>>>current
>>>>>>>>>>> plugin is
>>>>>>>>>>> >>> from git, then be careful not to
go above the git root.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM,
Michal Mocny <
>>>>>>>>>>> mmocny@chromium.org>wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>> Mulling this over a bit, I think
I would like a solution
>>>>>>>>>>>for
>>>>>>>>>>> specifying
>>>>>>>>>>> >>>> dependancies that would work
regardless of where/how the
>>>>>>>>>>> plugins are
>>>>>>>>>>> >>>> hosted, git or local.  If you
had:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> BB_PLUGINS/
>>>>>>>>>>> >>>> - plug1/
>>>>>>>>>>> >>>> - plug2/
>>>>>>>>>>> >>>> ...
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> (and plug1 depends on plug2),
then:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1
>>>>>>>>>>>..and..
>>>>>>>>>>>   cordova
>>>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> ..should both work without changing
all of the dependency
>>>>>>>>>>> tags in plug1.
>>>>>>>>>>> >>>>  Actually, the plugin author
should not have an explicit
>>>>>>>>>>>say
>>>>>>>>>>> in how a
>>>>>>>>>>> >>>> user
>>>>>>>>>>> >>>> manages these directories (except
in the directory
>>>>>>>>>>> structure).  Note
>>>>>>>>>>> >>>> that
>>>>>>>>>>> >>>> this situation applies whenever
a user clones your plugin
>>>>>>>>>>> repo to
>>>>>>>>>>> >>>> locally,
>>>>>>>>>>> >>>> or for the reverse direction,
when ever they add your
>>>>>>>>>>>plugins
>>>>>>>>>>> into their
>>>>>>>>>>> >>>> teams' git repo.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Right now, thats not possible,
because when installing
>>>>>>>>>>>from
>>>>>>>>>>> local path
>>>>>>>>>>> >>>> with
>>>>>>>>>>> >>>> url="." there is no way to know
which of the plugins
>>>>>>>>>>>parent
>>>>>>>>>>> directories
>>>>>>>>>>> >>>> to
>>>>>>>>>>> >>>> consider as the "root".  We
could resolve this using
>>>>>>>>>>>several
>>>>>>>>>>> ways, among
>>>>>>>>>>> >>>> them:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> (1) Jeffreys proposal: dropping
the url="." means "path
>>>>>>>>>>> relative to this
>>>>>>>>>>> >>>> plugin" (note however, that
I propose it also works when
>>>>>>>>>>> installing
>>>>>>>>>>> >>>> from a
>>>>>>>>>>> >>>> git repo).  Deprecate/warn against
using url=".".
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> (2) Support a new special file
to "mark" the plugin root
>>>>>>>>>>>dir
>>>>>>>>>>> so we can
>>>>>>>>>>> >>>> walk
>>>>>>>>>>> >>>> the directory tree to find the
valid target for url="."
>>>>>>>>>>>(ie,
>>>>>>>>>>> replace the
>>>>>>>>>>> >>>> requirement for a .git with
a requirement for a
>>>>>>>>>>> .cordova_repo, which BB
>>>>>>>>>>> >>>> and
>>>>>>>>>>> >>>> others could place within their
plugin bundle).
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> I like (1).
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> -Michal
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54
PM, Michal Mocny <
>>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>>> >>>> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> > Conceptually, I'm not sure
why the syntax for (2)
>>>>>>>>>>>shouldn't
>>>>>>>>>>> do what
>>>>>>>>>>> >>>> you
>>>>>>>>>>> >>>> > request when the url for
the original plugin was a local
>>>>>>>>>>> path?  Maybe
>>>>>>>>>>> >>>> just
>>>>>>>>>>> >>>> > a bug?
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> > -Michal
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at
9:38 PM, Jeffrey Heifetz <
>>>>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> >> We were working on
a redistribution of Cordova that
>>>>>>>>>>> included some
>>>>>>>>>>> >>>> plugins
>>>>>>>>>>> >>>> >> and ran into a use-case
not covered by the current
>>>>>>>>>>>plugin
>>>>>>>>>>> spec.[1]
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> Currently there are
two ways to specify a dependency
>>>>>>>>>>> >>>> >> 1. Using a combination
of url, commit and subdir which
>>>>>>>>>>> plugman will
>>>>>>>>>>> >>>> use
>>>>>>>>>>> >>>> >> to clone down a repo
and install
>>>>>>>>>>> >>>> >> 2. Set the url to ".",
skip the commit and specify a
>>>>>>>>>>> subdir relative
>>>>>>>>>>> >>>> to
>>>>>>>>>>> >>>> >> the root of the repo.
Plugman then runs git-rev parse
>>>>>>>>>>>to
>>>>>>>>>>> find the
>>>>>>>>>>> >>>> root and
>>>>>>>>>>> >>>> >> install from there.
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> I would like to propose
a third way which would be
>>>>>>>>>>> relative to the
>>>>>>>>>>> >>>> >> current install and
not use git at all
>>>>>>>>>>> >>>> >> 3. Skip the url, skip
the commit and specify a subdir
>>>>>>>>>>> relative to the
>>>>>>>>>>> >>>> >> current plugin.xml.
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> This would allow us
to distribute a version of cordova
>>>>>>>>>>> with plugins
>>>>>>>>>>> >>>> to
>>>>>>>>>>> >>>> >> anyone without an unnecessary
requirement on git
>>>>>>>>>>> (considering the
>>>>>>>>>>> >>>> plugins
>>>>>>>>>>> >>>> >> are fully installed)
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> 1.
>>>>>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> 
>>>>>>>>>>>----------------------------------------------------------------
>>>>>>>>>>>-
>>>>>>>>>>>----
>>>>>>>>>>> >>>> >> 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.
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
>---------------------------------------------------------------------
>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.


---------------------------------------------------------------------
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
View raw message