incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Plugin Format and Spec
Date Tue, 26 Jun 2012 00:23:32 GMT
Not to mention - I believe if we upgrade our plugin to nodejs 0.8, it
won't work with older versions of nodejs possibly - so that's another
can of worms

On Mon, Jun 25, 2012 at 5:19 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