Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of braden@google.com designates
 209.85.214.43 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
In-Reply-To: 
 <CABiQX1WndYCJ_KA0sG_J855DkEAeT4+GQ3W5vsA4_EsrhbzyRQ@mail.gmail.com>
References: 
 <CAMk5LLn2AUk55UDFeWghu=GszBJ1bnH-mBQXkHsHA+OEULnXhQ@mail.gmail.com>
	<CAEeF2Te4R9ME_jpqYmosYSR8EJ_yy39dHLS_Yk=cJ61fByVH4A@mail.gmail.com>
	<65F0E694-2BAD-430D-AD36-884087C520AC@gmail.com>
	<CANpVHHw2=hqJiSB9UJndoQ570it5aC3gS5e1D2YduJEKz_5uXw@mail.gmail.com>
	<CAEeF2Tdy25Ozq+iBTeg2H=NheeF-UN4u1U8j8usb5b95YZzr1Q@mail.gmail.com>
	<CAMk5LLnMyTxnpsAkUBb1DPi1GBY3-OxtoC=YX0hNoF6L00hV7A@mail.gmail.com>
	<CAEeF2TdqCeB3gNPfys+LyhMsPOmXw4eYq-JAWSrPcpUnawdDCQ@mail.gmail.com>
	<CANpVHHwCzWMti8==mo3TfGQFdKwC7s3KsxQb0mFEE0naN0gx5w@mail.gmail.com>
	<CAMk5LLmYQB6T__mXURf74v8TcrUckZgTBWJR0oiL+VAbLVOkfA@mail.gmail.com>
	<CANpVHHxuD4cy92skrSLSvwtJzp6sYiTRYATO+uiCa8xt8H9b3w@mail.gmail.com>
	<CADVgkyNqa+=uTeDF=dgDnLgw8vwTqwEu43_H=Fz_OP2Jk3C1sg@mail.gmail.com>
	<CAKP6k2uYnKpoyeqTdOSxZOghyTKux8VAYuS5j9BZs=-DSYZ5WA@mail.gmail.com>
	<CAEeF2TcRUw-P26ZJ-RQy+T4K3ikcan8giubo=i0ae024Cu0++Q@mail.gmail.com>
	<CANpVHHympH056vNjFG-c1G1tbDb1VcZbCGJ8ydG3Zu1D9wSSYg@mail.gmail.com>
	<B65A739C-F07D-4100-8B6B-C51719BC16A1@pulse-robotics.com>
	<35C02676BF7FD84F92417E42E09DD8DCBD0134D34B@nambx08.corp.adobe.com>
	<CABiQX1WndYCJ_KA0sG_J855DkEAeT4+GQ3W5vsA4_EsrhbzyRQ@mail.gmail.com>
Date: Fri, 27 Sep 2013 13:20:59 -0400
Message-ID: 
 <CAMk5LLmFFMABB1Mh4jKQZX7+nTZPwP8P6CN_3YDyb7sA6Wf0mw@mail.gmail.com>
Subject: Re: Updating plugin code on prepare
From: Braden Shepherdson <braden@chromium.org>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf301cc42ccd244504e760b59e

--20cf301cc42ccd244504e760b59e
Content-Type: text/plain; charset=ISO-8859-1

Symlinks in platforms/ are a problem because Xcode doesn't honour them, at
least last time we tried it.

I'm much more enthused about the --link concept than any syncing, though.
Also if someone wants to sync, they can already use rsync to do it manually.

Braden


On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve <agrieve@chromium.org>wrote:

> I think it'd be good to enumerate our options for workflow before we
> decided on which to implement (or maybe choose multiple).
>
> Tyler's idea about a sync command seems like it would be handy. Edit your
> plugin files within platforms/, and then run `cordova plugin copychanges
> org.my.plugin` to do a reverse copy of the source files back to the install
> source location of the plugin. Big caveat though is that you run the risk
> of prepare clobbering your changes. I think that's too killer a risk.
>
> Another thought is that we could use symlinks when running prepare. Have
> files within platforms/ symlink to files within plugins/, then symlink
> again back to their original sources. Would this work with editors in
> practice? I don't know, but worth exploring. Wikipedia says symlinks work
> on NTFS as of Vista.
>
> Braden / Michael - I think yours is a good idea as well. Although, I don't
> think we should encourage people to edit files within plugins/. They should
> edit their plugins from install point. We should record the install path,
> and maybe have prepare have a prepare --update-local-plugins.
>
> Any other ideas?
>
>
>
> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra <msierra@adobe.com> wrote:
>
> > Can you please file JIRAs on doc problems like this?   Existing overview
> > doc says you can use the CLI to bootstrap & hand off to an SDK &
> supporting
> > platform command-line utilities.  I take your comment to mean doc should
> > better stress that once you start working with platform tools downstream,
> > you can't go back to the CLI. Correct?
> >
> > --Mike Sierra
> >
> >
> > ________________________________________
> > From: Tyler Wilson [twilson@pulse-robotics.com]
> > Sent: Thursday, September 26, 2013 8:19 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Updating plugin code on prepare
> >
> > Re: IDEs: if it is the case that the CLI should not be used along with an
> > IDE, perhaps the documentation - including Getting Started Guides, etc. -
> > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > project files are created by the CLI, but they should not be opened and
> > used by Xcode. And you definitely should not edit code within the IDE".
> >
> > I just went to the main documentation site here -
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-and it appears it only mentions the new CLI interface. No mention of the
> > old bin/create method. Seems to me there may be communication problem
> here.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 6:11 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
> >
> > > @purplecabbage: I have the same workflow but I think the proposed
> > > solution is a step in the right direction. It would allow us to easily
> > > develop platform plugins without having to delete project/create
> > > project/install plugin/uninstall plugin constantly. The plugin would
> > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > development.
> > >
> > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > there is no point in creating projects with cordova-cli because
> > > everything gets blown on every build. I am not even sure we can make
> > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > the 3.0 release and that is why we have the create scripts and plugman
> > > approach. You should not be using cordova-cli either if you're doing
> > > some custom native dev that can't be pluginized (changing the main
> > > Activity.java or AppDelegate.m or whatever). If you're using
> > > cordova-cli just to create a project and then open an IDE to develop,
> > > you're probably doing it wrong. You should be creating a native
> > > project and using plugman instead.
> > >
> > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse <purplecabbage@gmail.com>
> wrote:
> > >>
> > >>> What does a watch mean?
> > >>> - if I reboot, is it still watched?
> > >>>
> > >>
> > >> No, this would start a process that lives until you CTRL+C.  You could
> > have
> > >> it run it in the background, or set it to start of startup, but that
> > would
> > >> be using local system tools, not part of the command itself.
> > >>
> > >> Ideally, "watch" should run "prepare" whenever you would have wanted
> it
> > to.
> > >> Though obviously that cannot be perfect, it can be a useful tool when
> > >> iterating.
> > >>
> > >>
> > >>>
> > >>> I think it would be best to consider separating development from
> > packaging
> > >>> in your use-case for workflow.
> > >>> If I am going to develop featureX as a plugin I would :
> > >>>
> > >>> 1. create a project for a single cordova platform, and develop the
> > feature
> > >>> as a native piece, and a js piece.
> > >>> 2. test thoroughly
> > >>> 3. create a project for a second cordova platform, and develop the
> > native
> > >>> bit, preserving the js from 1
> > >>> 4. test thoroughly
> > >>> 5. repeat steps 3+4 for any remaining platforms
> > >>> 6. package featureX as a plugin by organizing relevant bits in the
> > correct
> > >>> folder structure, and adding a plugin.xml
> > >>> 7. test each platform by installing with plugman
> > >>> 8. publish
> > >>>
> > >>
> > >> As a plugin developer, that is not my workflow.
> > >>
> > >> Typically for me its:
> > >>
> > >> Write a sample app/manual test for some new feature that isn't
> > implemented
> > >> yet.
> > >> Create a new plugin Foo for iOS & Android, and stub the
> implementation.
> > >> Implement feature A of plugin Foo for iOS, test, add it for Android,
> > test.
> > >> Implement feature B of plugin Foo for iOS, test, add it for Android,
> > test.
> > >> ...
> > >>
> > >> Usually the js implementation is shared, the auto tests are shared,
> and
> > the
> > >> sample test app is shared.
> > >>
> > >> Sure, I do platform specific stuff for testing and implementation,
> but I
> > >> certainly wouldn't say I do plugin development in platform isolation.
> > >>
> > >> Also, right now we do not have a "plugin create" command, and so
> leaving
> > >> the "packaging" step for last doesn't add affect total work.  But once
> > we
> > >> do have such a command, plugins could start packaged, and adding the
> > small
> > >> changes to plugin.xml as you need them is likely a good way to go.
> > >>
> > >> Finally, this workflow would get people out of the habit of making
> > changes
> > >> to the platform artifacts directly.  I'm not sure that can be entirely
> > >> avoided in all cases, but why shouldn't we work towards making that
> > easier?
> > >>
> > >>
> > >>> We seem to have this notion come up repeatedly that our users +
> plugin
> > >>> developers are working on multiple platforms at the same time, which
> I
> > >>> think is entirely false.
> > >>>
> > >>
> > >> Since we differ in opinion, how can we put this to the test?
> > >>
> > >> Also, we specifically make sure all our features address the needs of
> > those
> > >> doing single platform development, so in a world of 3.0+ cli, I really
> > >> don't see how we can not do the same to address the needs of those who
> > do
> > >> do multi-platform development, especially when we have a good proposal
> > of
> > >> how to do so and someone willing to do it.
> > >>
> > >>
> > >>> I also think we're trying to help the wrong people; If I am a
> > developer who
> > >>> is working on multiple platforms at once, and I have a bunch of
> devices
> > >>> attached, I probably also have the skills to set up my own grunt
> > continuous
> > >>> integration system. Setting up tooling for potential plugin
> developers
> > is
> > >>> the wrong approach, imho. We should actually just go and implement
> > some new
> > >>> plugin and evaluate the process instead of creating and imposing a
> > specific
> > >>> workflow.
> > >>>
> > >>
> > >> The first part of this argument has some merit, I agree.  We the
> > >> power-users have found ways to address our problems.  However, I think
> > that
> > >> with this change it means that even the end user can make changes to
> > plugin
> > >> folder as they find bugs/etc, and expect to see the change reflected
> > after
> > >> running prepare.  This is principle of least surprise, and just good
> > design.
> > >>
> > >> I also don't think we are imposing any specific workflow here, just
> > >> enabling a new one.  Personally I think that its quite surprising and
> > >> embarrassing that we haven't enabled this workflow since 3.0.
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> @purplecabbage
> > >>> risingj.com
> > >>>
> > >>>
> > >>> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b@brian.io> wrote:
> > >>>
> > >>>> I love the idea of a watch command.
> > >>>>
> > >>>>
> > >>>> On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <anis.kadri@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>>> Forgot about the existence of --link for a second. I think this is
> a
> > >>>>> good solution (not temporary). watch can be an enhancement to this
> > >>>>> solution. This might get people like Joe Bowser and other people
> who
> > >>>>> do native dev to give cordova-cli a try (only maybe though).
> > >>>>>
> > >>>>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > >>> braden@chromium.org
> > >>>>>
> > >>>>> wrote:
> > >>>>>> If the proposal above is temporary, what's permanent? cordova
> watch?
> > >>> I
> > >>>>> want
> > >>>>>> to make sure we're on the same page.
> > >>>>>>
> > >>>>>> Braden
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <anis.kadri@gmail.com
> >
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> No I didn't mean implement `plugman --watch`. I don't think
> plugman
> > >>>>>>> needs a `watch` command.
> > >>>>>>>
> > >>>>>>> I was indeed talking about `cordova watch` which should watch for
> > >>>>>>> changes in plugins/ (and maybe in merges/ and www/ as well) and
> > >>> update
> > >>>>>>> the platform projects (prepare?) on every change.  I am happy to
> > >>> know
> > >>>>>>> that it's on the wish list.
> > >>>>>>>
> > >>>>>>> As far as the original proposal, I believe it is a descent
> > temporary
> > >>>>>>> solution for plugin developers who want to use cordova-cli.
> > >>>>>>>
> > >>>>>>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <
> mmocny@chromium.org
> > >
> > >>>>> wrote:
> > >>>>>>>> Braden, thats has been on the wish list (cordova watch), but I
> > >>>> suspect
> > >>>>>>> Anis
> > >>>>>>>> was suggesting something different with plugman --watch, to do
> > >>>>>>> specifically
> > >>>>>>>> with plugin development.  Am I right, Anis?  How does your idea
> > >>>>> compare
> > >>>>>>>> with using --link with cordova watch?  Would plugman --watch be
> > >>>> useful
> > >>>>>>> for
> > >>>>>>>> non cli projects?
> > >>>>>>>>
> > >>>>>>>> -Michal
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > >>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>
> > >>>>>>>>> We've had a vague feature planned for a while now to do a
> cordova
> > >>>>>>> watch. It
> > >>>>>>>>> would watch your plugins/, www/, and merges/* for any changes.
> If
> > >>>> any
> > >>>>>>>>> changes are detected, it would re-run cordova prepare, so that
> > >>> your
> > >>>>>>> native
> > >>>>>>>>> projects are always up-to-date.
> > >>>>>>>>>
> > >>>>>>>>> I'm open to checking (hashes?) which files have changed and
> which
> > >>>>> have
> > >>>>>>> not,
> > >>>>>>>>> but hashing them all is touching them all anyway, and it might
> be
> > >>>>> faster
> > >>>>>>>>> for small files to just copy them instead of checking first.
> > >>> We'll
> > >>>>> have
> > >>>>>>> to
> > >>>>>>>>> try it and see; for v1 I'm going with the simple option of
> > >>> copying
> > >>>>>>>>> everything.
> > >>>>>>>>>
> > >>>>>>>>> Braden
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <
> > >>> mmocny@chromium.org
> > >>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> The idea for plugin dev outside of plugins/ folder was to use
> > >>>>> "plugin
> > >>>>>>> add
> > >>>>>>>>>> --link".  Matter of fact, braden suggested that "plugin
> create"
> > >>>>> should
> > >>>>>>>>>> default to --link-ing to some external location so that you
> > >>> don't
> > >>>>> risk
> > >>>>>>>>>> deleting your only copy inside plugins/.  (I personally don't
> > >>>> think
> > >>>>>>>>> thats a
> > >>>>>>>>>> necessary concern, but I think its a conversation for later).
> > >>>>>>>>>>
> > >>>>>>>>>> I'm not even sure what a 'watch' would do, just uninstall &
> > >>>> install
> > >>>>>>> each
> > >>>>>>>>>> time the plugin changes?  I think that ends up being just
> > >>>> slightly
> > >>>>>>> worse
> > >>>>>>>>>> than the current proposal if you factor in that we already do
> > >>>>> support
> > >>>>>>>>>> --link (except without the above change its been useless).
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> However, we may still want some form of 'watch' command for
> > >>> devs
> > >>>>> using
> > >>>>>>>>>> plugman directly.  I had assumed that those devs just edit in
> > >>>>> place,
> > >>>>>>>>> since
> > >>>>>>>>>> they don't use a prepare step anyway.
> > >>>>>>>>>>
> > >>>>>>>>>> -Michal
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <
> > >>>> anis.kadri@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> If we're talking about developing plugins inside the
> > >>>>>>>>>>> plugins/org.myplugin.id folder than I think it's a great
> > >>>>> workflow
> > >>>>>>> and
> > >>>>>>>>>>> I would just hide the cached version of plugin.xml inside
> > >>> that
> > >>>>>>>>>>> plugins/org.myplugin.id folder.
> > >>>>>>>>>>>
> > >>>>>>>>>>> However, if you're developing a plugin outside of a cordova
> > >>> CLI
> > >>>>>>>>>>> project, I think a `watch` (and add --watch) command is more
> > >>>>>>>>>>> appropriate. One of the reasons you would develop a plugin
> > >>>>> outside
> > >>>>>>> of
> > >>>>>>>>>>> a cordova CLI project is for easier version control (each
> > >>>> plugin
> > >>>>>>> would
> > >>>>>>>>>>> have its own repository). The other cool thing about `watch`
> > >>> is
> > >>>>> that
> > >>>>>>>>>>> it would copy the files that have actually changed and not
> > >>>>>>> everything
> > >>>>>>>>>>> (some plugins have a LOT of files [1]).
> > >>>>>>>>>>>
> > >>>>>>>>>>> [1] https://github.com/phonegap/phonegap-facebook-plugin
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> > >>>>> wjamesjong@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>> +1 This is a cleaner workflow and should reduce some
> > >>>> confusion.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -James Jong
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Sep 24, 2013, at 3:09 PM, Michal Mocny <
> > >>>> mmocny@chromium.org
> > >>>>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Just to add, the reason for the "if" statement in step (2)
> > >>>> is
> > >>>>>>> that
> > >>>>>>>>>>>>> uninstall & reinstall take a lot longer than just moving a
> > >>>> few
> > >>>>>>>>> files,
> > >>>>>>>>>>> which
> > >>>>>>>>>>>>> is the 99.9% case for most end users who aren't making
> > >>>>>>> modifications
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> plugins.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This way, we only do the heavy lifting if your plugin
> > >>>>> structure
> > >>>>>>>>>> actually
> > >>>>>>>>>>>>> changed.  Doing it automatically means we no longer have
> > >>> to
> > >>>>>>> advise
> > >>>>>>>>>> users
> > >>>>>>>>>>>>> that making edits inside plugin/ folder is useless.  Now
> > >>> we
> > >>>>> just
> > >>>>>>>>>> advise
> > >>>>>>>>>>>>> them to run "prepare" after making changes to either www/
> > >>> or
> > >>>>>>>>> plugins/.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This key insight was Braden's idea and I think its just an
> > >>>>>>> awesome
> > >>>>>>>>>>> change
> > >>>>>>>>>>>>> for workflow.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -Michal
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> > >>>>>>>>>>> braden@chromium.org>wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Michal and I were discussing how to make the plugin
> > >>>> developer
> > >>>>>>>>>>> experience
> > >>>>>>>>>>>>>> better, by having `cordova prepare` update the platform
> > >>>>> projects
> > >>>>>>>>>>> properly
> > >>>>>>>>>>>>>> when you change a plugin in place.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I propose the following changes:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 1. On plugin install, we cache the plugin.xml in
> > >>>>>>> $PROJECT/.cordova
> > >>>>>>>>>>>>>> somewhere.
> > >>>>>>>>>>>>>> 2. On 'cordova prepare', compare each plugin's plugin.xml
> > >>>>>>> against
> > >>>>>>>>> the
> > >>>>>>>>>>>>>> cached one.
> > >>>>>>>>>>>>>>   a. If they have changed, uninstall the plugin using
> > >>> the
> > >>>>> old
> > >>>>>>>>>>> plugin.xml,
> > >>>>>>>>>>>>>> then reinstall using the new one (and update the cached
> > >>>>>>>>> plugin.xml).
> > >>>>>>>>>>>>>>   b. If they are identical, copy all the native code
> > >>> files
> > >>>>> from
> > >>>>>>>>> the
> > >>>>>>>>>>>>>> plugin into the project again.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> The idea is that you can change your plugin's native
> > >>> code,
> > >>>> JS
> > >>>>>>>>>> modules,
> > >>>>>>>>>>> or
> > >>>>>>>>>>>>>> assets, and after a prepare you'll be running the latest.
> > >>>> We
> > >>>>>>>>> already
> > >>>>>>>>>>> have
> > >>>>>>>>>>>>>> cordova plugin add foo --link, but it wasn't very useful.
> > >>>>> This
> > >>>>>>> will
> > >>>>>>>>>>> make
> > >>>>>>>>>>>>>> plugin development a much smoother flow, without too much
> > >>>>>>>>>>> implementation
> > >>>>>>>>>>>>>> effort.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Checking for changes to plugin.xml lets us know that no
> > >>>> files
> > >>>>>>> have
> > >>>>>>>>>> been
> > >>>>>>>>>>>>>> added or removed, that <config-file> edits haven't
> > >>> changed,
> > >>>>> and
> > >>>>>>> so
> > >>>>>>>>>> on,
> > >>>>>>>>>>>>>> meaning that simply copying the native code again will be
> > >>>>>>>>> sufficient.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> What do people think? Any gotchas that I overlooked?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Braden
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>
> > >>>
> >
>

--20cf301cc42ccd244504e760b59e--