incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Plugin Format and Spec
Date Tue, 26 Jun 2012 00:27:54 GMT
Yes 0.8.x is stable, so we should be expecting more and more people to
move to it soon.

Cheers,
  Jesse

Sent from my iPhone5

On 2012-06-25, at 5:20 PM, Shazron <shazron@gmail.com> wrote:

> Talked to Brian and Anis.
>
> It was explained to me that even numbered versions are considered
> unstable, etc - so it's expected for devs to use a more stable
> version.
>
> I'm just considering the most common scenario - where people will
> download the latest node version 0.8 (regular dev users, not us)
>
> There's three approaches for us:
> 1. They downloaded 0.8 - tell them to downgrade, using
> https://github.com/isaacs/nave to 0.6
> 2. Upgrade our plugin to work with 0.8
> 3. Tell them to clean install 0.6 http://nodejs.org/dist/
>
> My thinking is #2 would be easiest for users, but if we are going with
> 0.6, we will have to document the steps etc for #1 and/or #3
>
> Shaz
>
> On Mon, Jun 25, 2012 at 4:52 PM, Shazron <shazron@gmail.com> wrote:
>> It's definitely a blocker IMO. 0.8 is the latest shipped version, and
>> it doesn't work with it.
>> Maybe you'll disagree, but users will.
>>
>> On Mon, Jun 25, 2012 at 4:36 PM, Filip Maj <fil@adobe.com> wrote:
>>> Yep, 0.6.8.
>>>
>>> $ node -v
>>> v0.6.8
>>>
>>>
>>> On 6/25/12 4:32 PM, "Jesse" <purplecabbage@gmail.com> wrote:
>>>
>>>> 0.6.8 ? Is your toaster unplugged Fil?
>>>> I am in windows and running without issue :
>>>> $ node -v => v0.6.18
>>>>
>>>>
>>>> On Mon, Jun 25, 2012 at 4:29 PM, Filip Maj <fil@adobe.com> wrote:
>>>>
>>>>> I wouldn┬╣t call that a blocker..
>>>>>
>>>>> Pluginstall works fine with node 0.6.8 too.
>>>>>
>>>>> I was using 0.6.6, some dependencies in pluginstall require at least
>>>>> node
>>>>> 0.6.7, so I upgraded to 0.6.8. Works fine.
>>>>>
>>>>> On 6/25/12 3:59 PM, "Shazron" <shazron@gmail.com> wrote:
>>>>>
>>>>>> pluginstall blocker:
>>>>>> https://github.com/alunny/node-xcode/issues/3
>>>>>> https://issues.apache.org/jira/browse/CB-631
>>>>>>
>>>>>> Only works with node 0.6.17
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 25, 2012 at 2:09 PM, Jesse <purplecabbage@gmail.com>
wrote:
>>>>>>> We could use an 'engine' type specification similar to npm :
>>>>>>> "engine": "node >= 0.4.1"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri
>>>>>>> nkwrap/
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 25, 2012 at 2:02 PM, Filip Maj <fil@adobe.com>
wrote:
>>>>>>>
>>>>>>>> Ideally, I would think we do NOT plan on doing that post-2.0.
That
>>>>>>>> said,
>>>>>>>> our current deprecation policy, last I checked, was "6 months
from
>>>>>>>> now",
>>>>>>>> which does not guarantee that the API will not change between
minor
>>>>>>>> revisions.
>>>>>>>>
>>>>>>>> Thus, the conversation turns back to project versioning and
>>>>>>>> deprecation.
>>>>>>>>
>>>>>>>> Mike and I spoke about this this morning. I think both of
us support
>>>>>>>> the
>>>>>>>> idea of moving to semantic versioning for 2.0 and beyond.
>>>>>>>>
>>>>>>>> On 6/25/12 1:45 PM, "Anis KADRI" <anis.kadri@gmail.com>
wrote:
>>>>>>>>
>>>>>>>>> Agreed fil, but are we planning on doing that for future
releases ?
>>>>>>>> If yes
>>>>>>>>> that YAH we should support versions and the solution
you described
>>>>> is
>>>>>>>>> certainly an option. But if I were a plugin developer,
I would not
>>>>>>>> want to
>>>>>>>>> update it every month to keep up with Cordova releases.
>>>>>>>>> I don't disagree that there could be an Cordova version
in the
>>>>>>>> manifest
>>>>>>>>> file that allows plugin developers to target a specific
version of
>>>>>>>> Cordova
>>>>>>>>> (which would mean that the plugin was tested with that
version but
>>>>>>>> might
>>>>>>>>> also work with newer versions).
>>>>>>>>>
>>>>>>>>> On Mon, Jun 25, 2012 at 1:33 PM, Filip Maj <fil@adobe.com>
wrote:
>>>>>>>>>
>>>>>>>>>> Yes, it has changed every month. Pretty much every
minor revision
>>>>>>>> from
>>>>>>>>>> 1.0
>>>>>>>>>> to 1.9 has changed the API (at least on Android).
>>>>>>>>>>
>>>>>>>>>> On 6/25/12 1:26 PM, "Anis KADRI" <anis.kadri@gmail.com>
wrote:
>>>>>>>>>>
>>>>>>>>>>> Right but does the plugin interface change every
month too ? A
>>>>>>>> plugin
>>>>>>>>>> that
>>>>>>>>>>> works with Cordova 1.x.x is not supposed to work
with Cordova
>>>>>>>> 1.y.y ?
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 25, 2012 at 1:18 PM, Filip Maj <fil@adobe.com>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> You don't see any reason why plugins should
support different
>>>>>>>>>> versions
>>>>>>>>>>>> of
>>>>>>>>>>>> cordova? Cordova gets released every month.
This seems like a
>>>>>>>> pretty
>>>>>>>>>>>> important thing to figure out IMO
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/25/12 1:12 PM, "Anis KADRI" <anis.kadri@gmail.com>
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I think we should agree on a spec (plugin
package and plugin
>>>>>>>>>> interface)
>>>>>>>>>>>>> and
>>>>>>>>>>>>> stick to it. As long as we don't break
the plugin interface,
>>>>> I
>>>>>>>> don't
>>>>>>>>>>>> see
>>>>>>>>>>>>> any reason why plugins should support
multiple versions of
>>>>>>>> Cordova.
>>>>>>>>>> If
>>>>>>>>>>>>> there are any, I'd love to hear them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jun 25, 2012 at 1:01 PM, Filip
Maj <fil@adobe.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Back onto the versioning question..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Do we want to support different
version of the cordova
>>>>>>>>>> framework
>>>>>>>>>>>> in
>>>>>>>>>>>>>> plugins, within a single repo, across
versions that changed
>>>>>>>> the
>>>>>>>>>>>>>> native/javascript plugin API?
>>>>>>>>>>>>>> 2. How?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the answer to (1) is yes, one
idea for (2) might be
>>>>> nesting
>>>>>>>>>>>> another
>>>>>>>>>>>>>> directory level in the all of the
source directories that
>>>>>>>> contains
>>>>>>>>>>>> the
>>>>>>>>>>>>>> version number supported. For example:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/android/1.5.0/*.java
>>>>>>>>>>>>>> src/android/1.8.1/*.java
>>>>>>>>>>>>>> www/1.5.0/childbrowser.js
>>>>>>>>>>>>>> www/1.8.1/childbrowser.js
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could get gnarly real quick though.
Another, cleaner
>>>>>>>>>> implementation
>>>>>>>>>>>> in
>>>>>>>>>>>>>> terms of file system "noise" might
be to employ a git
>>>>> branches
>>>>>>>>>>>>>> convention.. But that would enforce
a git dependency.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just brainstorming / thinking out
loud. Both are probably
>>>>> bad
>>>>>>>>>> ideas
>>>>>>>>>>>> :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/25/12 11:41 AM, "Michael Brooks"
>>>>>>>> <michael@michaelbrooks.ca>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We may also want to describe
testing from JavaScript and
>>>>>>>> Native.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would also like to see a repository
called
>>>>>>>>>>>> "cordova-plugin-template"
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> is a boilerplate to start writing
any plugin. The idea is
>>>>>>>> that
>>>>>>>>>> users
>>>>>>>>>>>>>> start
>>>>>>>>>>>>>>> with something that works, with
tests, and documentation
>>>>>>>>>>>> boilerplate -
>>>>>>>>>>>>>>> perhaps it can be an echo plugin
since that has a minimal
>>>>>>>>>> footprint.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jun 25, 2012 at 11:28
AM, Filip Maj
>>>>> <fil@adobe.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Looks great. I'll add some
detail to the list you have
>>>>>>>> here.
>>>>>>>>>> I'd
>>>>>>>>>>>>>>>> recommend
>>>>>>>>>>>>>>>> tweaking the order a little
bit; introducing the JS
>>>>> before
>>>>>>>> the
>>>>>>>>>>>> native
>>>>>>>>>>>>>>>> APIs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> # Plugin Author Guide
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - plugin package format ->
points to Andrew's plugin
>>>>> spec
>>>>>>>>>>>>>>>> - js api
>>>>>>>>>>>>>>>> --- basically documenting
exec(). Service, action,
>>>>>>>> callbacks,
>>>>>>>>>>>>>> arguments.
>>>>>>>>>>>>>>>> What about how arguments
are translated from JS types
>>>>>>>> (string,
>>>>>>>>>>>>>> number,
>>>>>>>>>>>>>>>> objects, etc) to native types
for each platform?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - native api
>>>>>>>>>>>>>>>> --- ios
>>>>>>>>>>>>>>>> --- android
>>>>>>>>>>>>>>>> --- blackberry
>>>>>>>>>>>>>>>> --- windowsphone
>>>>>>>>>>>>>>>> --- bada
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6/25/12 11:16 AM, "Brian
LeRoux" <b@brian.io> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Biggest question is how
to document. My thinking is
>>>>> that
>>>>>>>> we
>>>>>>>>>> want
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> specify the PluginPackage
so that PluginInstall works.
>>>>> So
>>>>>>>> the
>>>>>>>>>>>> docs
>>>>>>>>>>>>>>>>> would read like this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> # Plugin Author Guide
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - plugin package format
>>>>>>>>>>>>>>>>> - native api
>>>>>>>>>>>>>>>>> --- ios
>>>>>>>>>>>>>>>>> --- android
>>>>>>>>>>>>>>>>> --- blackberry
>>>>>>>>>>>>>>>>> --- windowsphone
>>>>>>>>>>>>>>>>> --- bada
>>>>>>>>>>>>>>>>> - js api
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thoughts? (If this looks
good I will update the issue.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jun 25, 2012
at 10:50 AM, Filip Maj
>>>>>>>> <fil@adobe.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Hah Michael and I
were just talking about that..
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will send a pull
request to Andrew's draft spec
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6/25/12 10:46
AM, "Brian LeRoux" <b@brian.io>
>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> npm does this
w/ an 'engines' attribute on
>>>>> package.json
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jun 25,
2012 at 10:26 AM, Filip Maj
>>>>>>>> <fil@adobe.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> One more
thing that came to mind is how to support
>>>>>>>>>> different
>>>>>>>>>>>>>>>> versions
>>>>>>>>>>>>>>>>>>>> of Cordova?
Any ideas?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> From: Andrew
Lunny
>>>>>>>>>>>> <alunny@gmail.com<mailto:alunny@gmail.com>>
>>>>>>>>>>>>>>>>>>>> Reply-To:
>>>>> "alunny@gmail.com<mailto:alunny@gmail.com>"
>>>>>>>>>>>>>>>>>>>> <alunny@gmail.com<mailto:alunny@gmail.com>>
>>>>>>>>>>>>>>>>>>>> To: Default
User Nam
>>>>>>>> <fil@adobe.com<mailto:fil@adobe.com
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>>>>>>> "callback-dev@incubator.apache.org<mailto:
>>>>>>>>>>>>>>>> callback-dev@incubator.apache
>>>>>>>>>>>>>>>>>>>> .o
>>>>>>>>>>>>>>>>>>>> rg>"
>>>>>>>>>>>>>>>>>>>> <callback-dev@incubator.apache.org<mailto:
>>>>>>>>>>>>>>>> callback-dev@incubator.apache
>>>>>>>>>>>>>>>>>>>> .o
>>>>>>>>>>>>>>>>>>>> rg>>
>>>>>>>>>>>>>>>>>>>> Subject:
Re: Plugin Format and Spec
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11 June
2012 13:50, Filip Maj
>>>>>>>>>>>>>>>> <fil@adobe.com<mailto:fil@adobe.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Nice work
Andrew! I suggest taking this and moving
>>>>> to
>>>>>>>> a
>>>>>>>>>>>> cordova
>>>>>>>>>>>>>>>> wiki
>>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>>> (assuming
all committers are on board to adopting
>>>>>>>> this as
>>>>>>>>>> the
>>>>>>>>>>>>>> basis
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> plugin spec)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A link on
the Cordova wiki is probably the best
>>>>> place
>>>>>>>> to
>>>>>>>>>>>> start
>>>>>>>>>>>>>> - we
>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> get some
more feedback from plugin authors and app
>>>>>>>>>> developers
>>>>>>>>>>>>>> (i.e.
>>>>>>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>>>>> this as "a
way to write plugins" rather than "the
>>>>>>>> official
>>>>>>>>>>>> way to
>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>>>>>> plugins").
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Is target-dir
necessary for the <source-file>
>>>>>>>> element? For
>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>> files,
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> tooling could
take a peak inside the .java file and
>>>>>>>>>> extract
>>>>>>>>>>>> out
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> package name
from the file, no? Phonegap build
>>>>> already
>>>>>>>>>> does
>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> PhoneGap
Build did do this, but no longer supports
>>>>>>>>>> uploading
>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>>>>> Java files.
Only plugins with a manifest are
>>>>> supported.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm torn
- one of the goals of this format is to
>>>>> make
>>>>>>>> it
>>>>>>>>>> as
>>>>>>>>>>>>>> easy as
>>>>>>>>>>>>>>>>>>>> possible
to write tools that use it as possible.
>>>>> Right
>>>>>>>>>> now, a
>>>>>>>>>>>>>> tool
>>>>>>>>>>>>>>>>>>>> reads
>>>>>>>>>>>>>>>>>>>> one file
(plugin.xml) and moves source files
>>>>> (ignoring
>>>>>>>>>> config
>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> the moment).
I'd prefer it wasn't "read one file,
>>>>> then
>>>>>>>> read
>>>>>>>>>>>> each
>>>>>>>>>>>>>>>> .java
>>>>>>>>>>>>>>>>>>>> file to discover
where to move it".
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> One option
is to use the id attribute on the
>>>>> top-level
>>>>>>>>>> plugin
>>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>>>>>>> to resolve
the path, but that doesn't handle the
>>>>> case
>>>>>>>> where
>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>>>> Java files
will have different paths. I wonder if
>>>>>>>> there are
>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>> complex
>>>>>>>>>>>>>>>>>>>> plugins around
we can try to convert to see where
>>>>> the
>>>>>>>> pain
>>>>>>>>>>>> points
>>>>>>>>>>>>>>>> are.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Adding the
ability to modify existing parts of a
>>>>>>>> native
>>>>>>>>>>>>>> platform's
>>>>>>>>>>>>>>>>>>>> config
>>>>>>>>>>>>>>>>>>>> document
to the <config-file> portion might be
>>>>>>>> needed..
>>>>>>>>>>>> Although
>>>>>>>>>>>>>>>> Ive
>>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>>> to dig up
a use case. Will dig around more.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Agreed -
also things like target OS/SDK versions
>>>>> may
>>>>>>>> be
>>>>>>>>>>>>>> required by
>>>>>>>>>>>>>>>>>>>> certain plugins
(i.e. this plugin uses an iOS 6 API,
>>>>>>>> so we
>>>>>>>>>>>> need
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> update your
project to iOS 6). Probably the best
>>>>>>>> approach
>>>>>>>>>>>> there
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> warn/prompt
the user before proceeding.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +1 agree
that <resource-file> and <header-file> is
>>>>>>>>>> redundant.
>>>>>>>>>>>>>>>> Tooling
>>>>>>>>>>>>>>>>>>>> should be
able to distinguish this so merging with
>>>>>>>>>>>> <source-file>
>>>>>>>>>>>>>>>>>>>> makes a
>>>>>>>>>>>>>>>>>>>> lot of sense.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Looking good!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 6/8/12
6:40 PM, "Andrew Lunny"
>>>>>>>>>>>>>>>>>>>> <alunny@gmail.com<mailto:alunny@gmail.com>>
wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've
posted to this list before about
>>>>> pluginstall[1],
>>>>>>>> the
>>>>>>>>>>>> tool
>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>> developed
as part of working on PhoneGap Build and
>>>>>>>>>> requiring
>>>>>>>>>>>>>>>>>>>>> programmatic
>>>>>>>>>>>>>>>>>>>>> installation
of Cordova plugins.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've
now written up a spec for the format that
>>>>>>>> pluginstall
>>>>>>>>>>>> uses
>>>>>>>>>>>>>> - I
>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>> it's
generally useful for Cordova plugin
>>>>> installation
>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> manipulation.
>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>> spec
is available on GitHub:
>>>>>>>>>>>>>>>>>>>>> https://github.com/alunny/cordova-plugin-spec
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Issues
and/or pull requests and/or forks welcome.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>> Andrew
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [1] https://github.com/alunny/pluginstall
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> @purplecabbage
>>>>>>> risingj.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> @purplecabbage
>>>> risingj.com
>>>

Mime
View raw message