cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Configuring the File plugin
Date Tue, 14 Jan 2014 21:14:14 GMT
I agree with the plugin broken by default, and requiring From my
experience, doing anything fancy for users to ease migration rarely does
what is intended - and causes more problems, my 2c

FileMigrator plugin is great, externalizes the problem


On Tue, Jan 14, 2014 at 1:10 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Migration isn't possible by default because the current location for
> Android is the root of the SD Card.
>
> The goal here is to put PERSISTENT under Library, but to also make
> other interesting places available via other URLs / FileSystem
> objects.
>
> So far my fav. is to have the plugin broken by default so that users
> will be forced to add a pref to set either old / new location. Really
> don't want new apps being written with data in the wrong spot.
>
> For the case of configuring custom locations, I think a native API is
> more workable than configuration.
>
>
> On Tue, Jan 14, 2014 at 4:05 PM, Tommy-Carlos Williams
> <tommy@devgeeks.org> wrote:
> > Sorry…
> >
> > I have been trying not to chicken-little this thread, but I just need
> some clarification on some things.
> >
> > My understanding, please correct me if I am wrong:
> >
> > The “old" location on iOS is not the best location for files the dev
> doesn’t want exposed, but it *is* where they should be if the dev wants
> them accessible via iTunes
> >
> > Assuming this is correct, I have some questions:
> >
> > 1. What if that’s where the dev *wants* the files to go?
> > 2. Could files still be backed up by iCloud if they were in the new
> location?
> >
> >
> > It feels like making assumptions about what kinds of files developers
> are using the File API for.
> >
> > :/
> >
> > - tommy
> >
> >
> >
> > On 15 Jan 2014, at 7:09 am, Ian Clelland <iclelland@chromium.org> wrote:
> >
> >> On Tue, Jan 14, 2014 at 2:52 PM, Brian LeRoux <b@brian.io> wrote:
> >>
> >>> Wait, users lose data IF they upgrade the plugin. Is that correct?
> >>>
> >>
> >> *If* we change the default storage location, and *if* a developer
> upgrades
> >> the file plugin without looking too closely (because, hey, newer is
> always
> >> better, right?) and pushes a new version of the app to existing users,
> then
> >> yes, users will lose access to the data that they previously had stored.
> >>
> >> Technically, they aren't losing the data; it's still possible to get to
> it,
> >> someday, maybe, if the developer does a lot of work to fix the app, and
> it
> >> hasn't ended up in some inconsistent state -- it's not deleted, though.
> >>
> >> And I do believe that developers will do that, too. Maybe not the good
> ones
> >> :) But people will gloss over the upgrade instructions, read the
> warnings
> >> without thinking "oh, that affects my users", and publish away.
> >>
> >>
> >>>
> >>>
> >>> On Tue, Jan 14, 2014 at 10:53 AM, Ian Clelland <iclelland@chromium.org
> >>>> wrote:
> >>>
> >>>> On Tue, Jan 14, 2014 at 1:44 PM, Brian LeRoux <b@brian.io> wrote:
> >>>>
> >>>>> So, to be clear and terse: what are the use cases / why are we adding
> >>>> more
> >>>>> config?
> >>>>>
> >>>>
> >>>> 1. NSDocumentsDirectory is a stupid place to put the HTML filesystem
> on
> >>>> iOS. NSLibraryDirectory is a more sensible place, and I'd love to
> change
> >>> it
> >>>> as part of this rollout, *but*
> >>>> 2. If we change it unilaterally, real users are going to lose access
> to
> >>>> real data.
> >>>>
> >>>> Also,
> >>>> 3. The File plugin is much more modular now, and we could potentially
> >>> have
> >>>> a whole ecosystem of Filesystem providers making filesystem-shaped
> >>> things,
> >>>> but it needs to be configurable to be useful.
> >>>>
> >>>> #3 is less important at the moment, but becomes more compelling if we
> >>>> provide the machinery for other devs to take advantage of it.
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> On Tue, Jan 14, 2014 at 10:34 AM, Ian Clelland <
> iclelland@chromium.org
> >>>>>> wrote:
> >>>>>
> >>>>>> On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve <
> >>> agrieve@chromium.org
> >>>>>>> wrote:
> >>>>>>
> >>>>>>> On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland <
> >>>> iclelland@chromium.org
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>> On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve <
> >>>> agrieve@chromium.org
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I think we need two things for transitioning to
different
> >>>>> PERSISTENT /
> >>>>>>>>> TEMPORARY locations:
> >>>>>>>>> 1. The ability for the user to retrieve the files
at the old
> >>>>> location
> >>>>>>>>> (so they can be moved to the new location)
> >>>>>>>>> 2. The ability to turn turn on the change with a
switch (e.g.
> >>>>>>>>> <preference name="IosUseLegacyFileSystemPath"
value="true" />)
> >>>>>>>>>
> >>>>>>>>> I'd love for the default to be the new locations
so that new
> >>> apps
> >>>>>>>>> don't forget to turn on the preference and find
out they need to
> >>>>>>>>> migrate later on.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> This is the really dangerous bit, though. If we make
the default
> >>>>>> anything
> >>>>>>>> but the current behaviour, then devs *will* update their
plugins
> >>>> and
> >>>>>>> push,
> >>>>>>>> and users *will* lose the ability to access old saved
files. We
> >>>> will
> >>>>>>>> absolutely encounter the situation where developers
test their
> >>> app
> >>>>> with
> >>>>>>>> blank filesystems, and everything works fine, but data
is
> >>> rendered
> >>>>>>>> inaccessible to users who upgrade from an old version.
And I'm
> >>> sure
> >>>>>> it'll
> >>>>>>>> happen no matter how loudly we announce the change.
> >>>>>>>>
> >>>>>>>> I would sooner make the new plugin be "broken by default",
so
> >>> that
> >>>>> the
> >>>>>>> app
> >>>>>>>> doesn't even start until you add a configuration preference,
one
> >>>> way
> >>>>> or
> >>>>>>> the
> >>>>>>>> other. Then we could recommend at that time, "if you
have an
> >>>> existing
> >>>>>> app
> >>>>>>>> with users, then use the old value; if this is a brand
new app,
> >>> use
> >>>>> the
> >>>>>>> new
> >>>>>>>> one".
> >>>>>>>
> >>>>>>> I really like this idea!
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Also - the simpler our instructions can be, the better.
I don't
> >>>> think
> >>>>>>>>> most devs even realize that they are doing a foolish
thing with
> >>>> the
> >>>>>>>>> way things are set up right now, so telling them
to configure
> >>>> their
> >>>>>>>>> own paths might put too much of a burden on them
(they'd have to
> >>>>> learn
> >>>>>>>>> where files should go, and then also figure out
how our config
> >>>>> syntax
> >>>>>>>>> works).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> True. The simple case should be as simple as possible.
Ideally,
> >>>> doing
> >>>>>>>> nothing at all should get them some reasonable behaviour,
> >>>> compatible
> >>>>>> with
> >>>>>>>> previous versions.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The case of adding new FS roots is compelling, but
I think most
> >>>>> users
> >>>>>>>>> would appreciate FS roots for content, assets, sdcard,
etc to be
> >>>>>>>>> pre-built-in rather than have to wire them up themselves.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Agreed. Those ones should be available out-of-the-box,
either as
> >>>> part
> >>>>>> of
> >>>>>>>> File, or as part of a related plugin. (Leaning towards
File,
> >>> since
> >>>> it
> >>>>>> is
> >>>>>>>> already providing content and assets filesystem URLs)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> One thing that jumped out to me is the src= argument:
> >>>>>>>>> <filesystem name="documents"
> >>>>>>>>>    type="local-filesystem"
> >>>>>>>>>    prefix="cdvfile://localhost/documents"
> >>>>>>>>>    src="Documents" />
> >>>>>>>>>
> >>>>>>>>> If the goal is for these to be customizable, then
it's not that
> >>>>>>>>> flexible to use pre-defined values in the src= argument.
Perhaps
> >>>>>>>>> instead of using config.xml, the File plugin could
have a
> >>>>>>>>> registerFileSystemRoot(name, type, prefix, rootPath)
function
> >>> that
> >>>>>>>>> could be used for this purpose. That way plugins
could compute
> >>>> their
> >>>>>>>>> root paths and then call this function at plugin
init time.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That was mostly an off-the-top-of-my-head strawman for
the
> >>> format.
> >>>>>>> However,
> >>>>>>>> it does address the issue of how to specify "this filesystem
> >>> lives
> >>>> at
> >>>>>> the
> >>>>>>>> NSTemporaryDirectory location; that one lives at
> >>>> NSLibraryDirectory",
> >>>>>>>> without having to know the real filesystem path for
those things.
> >>>>>>>>
> >>>>>>>> I expected that the interpretation of something like
a "src"
> >>>>> attribute
> >>>>>>>> would be very dependent on the filesystem type, and
specialized
> >>> to
> >>>>> that
> >>>>>>>> type, rather than representing an absolute device fs
path.
> >>>>>>>
> >>>>>>> If the valid values here are pre-determined by the FS type,
then I
> >>>>>>> don't know why we'd have this configuration.
> >>>>>>> Let's just expose all of the roots that the FS knows about.
If we
> >>>> want
> >>>>>>> to be able to toggle some on/off, then let's add a pref
for
> >>>>>>> "fs-type-whitelist" which is just a comma-separated-list.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> A comma-separated list isn't so bad; in fact, given the call
> >>> signature
> >>>> of
> >>>>>> requestFileSystem, the *order* of items in that list may be
the
> >>>> critical
> >>>>>> thing. A CSL is certainly easier to shoehorn into our existing
> config
> >>>>>> parsing than a whole block of XML, even if it's a bit uglier.
> >>>>>>
> >>>>>> What about something shaped like
> >>>>>>
> >>>>>> <preference name="filesystems"
> >>>> value="temporary,documents,assets,library"
> >>>>>> />
> >>>>>>
> >>>>>> Then you could switch "documents" and "library" in the list,
and you
> >>>>> would
> >>>>>> be storing files in the new position (by the definition of
> >>>>>> window.PERSISTENT).
> >>>>>>
> >>>>>> Ian
> >>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Another thing that occurred to me (maybe off topic?):
Why:
> >>>>>>>>> cdvfile://localhost/documents
> >>>>>>>>> instead of:
> >>>>>>>>> cdvfile://documents/
> >>>>>>>>> Looking at this URL-wise, I think it would be a
nice-to-have to
> >>>> have
> >>>>>>>>> the type encoded as the hostname so that root-relative
URLs
> >>> would
> >>>>> work
> >>>>>>>>> with the URLS.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> We discussed this at the Waterloo meetup, and there
was
> >>> definitely
> >>>>> some
> >>>>>>>> push for having the authority part in the URL be the
real
> >>> authority
> >>>>>>>> (localhost), for consistent URL handling.
> >>>>>>>>
> >>>>>>>> Having the FS type be the authority would make some
of the
> >>> internal
> >>>>> URL
> >>>>>>>> parsing easier, but I don't know if it causes problems
anywhere
> >>>> else.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Could we get away with just two parameters to each
FS root?
> >>>>>>>>> 1. Name (use this to determine prefix as cdvfile://${name})
> >>>>>>>>> 2. src (URI to be considered the root of the FS).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Those are, internally, the parameters used by the "local
> >>>> filesystem"
> >>>>> FS
> >>>>>>>> type (i.e., not "content" or "assets library".) The
actual
> >>>> device-FS
> >>>>>>> root,
> >>>>>>>> though, is currently determined at run time by the device,
based
> >>> on
> >>>>>>> whether
> >>>>>>>> it is the temporary or persistent FS.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Jan 13, 2014 at 4:29 PM, Ian Clelland <
> >>>>> iclelland@chromium.org
> >>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>> On Mon, Jan 13, 2014 at 3:21 PM, Jesse <
> >>> purplecabbage@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Will any of the following work?
> >>>>>>>>>>>
> >>>>>>>>>>> <img src="cdvfile://localhost/persistent/1.png"/>
> >>>>>>>>>>>
> >>>>>>>>>>> xhr.open("GET","cdvfile://localhost/persistent/data.txt");
> >>>>>>>>>>>
> >>>>>>>>>>> <link rel="stylesheet" type="text/css"
> >>>>>>>>>>> href="cdvfile://localhost/persistent/style.css"/>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> If the new file plugin is installed, and the
file exists, then
> >>>> the
> >>>>>>> first
> >>>>>>>>>> three of those should definitely work (assuming
the default
> >>>>>>>>> configuration).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> <a href="cdvfile://localhost/temporary/site/temp.html"
> >>>>>>>>>>> target="_blank">Review Site</a>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I'm not sure about this -- haven't tried it.
If it's doing
> >>>>>> navigation,
> >>>>>>>>> then
> >>>>>>>>>> I don't know how it plays with the fact that
plugins get
> >>>> unloaded
> >>>>> or
> >>>>>>>>> reset
> >>>>>>>>>> at some point.
> >>>>>>>>>>
> >>>>>>>>>> The in-app-browser version of this:
> >>>>>>>>>>
> >>>>>>>>>> window.open("cdvfile://localhost/temporary/site/temp.html",
> >>>>>> "_blank")
> >>>>>>>>>>
> >>>>>>>>>> should work just fine.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> @purplecabbage
> >>>>>>>>>>> risingj.com
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Jan 13, 2014 at 10:37 AM, Brian
LeRoux <b@brian.io>
> >>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I am apprehensive about making this
surface configurable.
> >>> (I
> >>>>> can
> >>>>>>> live
> >>>>>>>>> w/
> >>>>>>>>>>>> our own protocol cdvfile:// personally).
> >>>>>>>>>>>>
> >>>>>>>>>>>> The main use case is being able to add
custom storage
> >>>> providers
> >>>>>> in
> >>>>>>> the
> >>>>>>>>>>>> future?
> >>>>>>>>>>>>
> >>>>>>>>>>>> (Might be good to add this to the 'lets
talk configuration'
> >>>>>>> backlog /
> >>>>>>>>>>>> meeting.)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jan 13, 2014 at 7:32 AM, Ian
Clelland <
> >>>>>>> iclelland@chromium.org
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> The new File plugin is essentially
ready, for iOS and
> >>>> Android
> >>>>>>> (with,
> >>>>>>>>>>>>> hopefully, no breaking changes for
those or other
> >>>> platforms)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I had to move away from the "filesystem://"
URL scheme --
> >>>> on
> >>>>>>> Android
> >>>>>>>>>>> 4.4,
> >>>>>>>>>>>>> that scheme appears to be special,
and doesn't defer to
> >>>>>>>>>>>>> WebView.shouldInterceptRequest().
(I filed
> >>>>>>>>>>>>>
> >>>> https://code.google.com/p/chromium/issues/detail?id=333395on
> >>>>>>>>> Friday
> >>>>>>>>>>>> once
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>> had isolated the problem.) For now,
I've settled on
> >>>>>> "cdvfile://",
> >>>>>>>>> but
> >>>>>>>>>>> the
> >>>>>>>>>>>>> issue is open to bikeshedding, I
suppose.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> What I'd really like to open for
discussion though, is
> >>> the
> >>>>> idea
> >>>>>>> of
> >>>>>>>>>>> making
> >>>>>>>>>>>>> the whole plugin configuration,
er, configurable.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The URL scheme is one driving force
behind this; the
> >>>>> historical
> >>>>>>>>>>> locations
> >>>>>>>>>>>>> of the TEMPORARY and PERSISTENT
filesystems is another;
> >>> the
> >>>>> new
> >>>>>>>>> ability
> >>>>>>>>>>>> to
> >>>>>>>>>>>>> open up completely new filesystems
is a third.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm thinking of implementing a section
in config.xml that
> >>>>> would
> >>>>>>>>> define
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> names of the installed filesystems
available to a Cordova
> >>>>> app,
> >>>>>>> along
> >>>>>>>>>>> with
> >>>>>>>>>>>>> their type, the URL prefix to use,
and any other required
> >>>>>> details
> >>>>>>>>> (like
> >>>>>>>>>>>>> *where the files live*). Something
like this:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> <widget>
> >>>>>>>>>>>>>  <filesystems platform="android">
> >>>>>>>>>>>>>    <filesystem name="temporary"
type="local-filesystem"
> >>>>>>>>>>>>> prefix="cdvfile://localhost/temporary"
src="cache" />
> >>>>>>>>>>>>>    <filesystem name="persistent"
type="local-filesystem"
> >>>>>>>>>>>>> prefix="cdvfile://localhost/persistent"
src="Documents"
> >>> />
> >>>>>>>>>>>>>    <filesystem name="content"
type="content-filesystem"
> >>>>>>>>>>>>> prefix="content://" />
> >>>>>>>>>>>>>  </filesystems>
> >>>>>>>>>>>>> </widget>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> or
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> <widget>
> >>>>>>>>>>>>>  <feature name="File">
> >>>>>>>>>>>>>    <filesystems platform="android">
> >>>>>>>>>>>>>      <filesystem name="temporary"
> >>> type="local-filesystem"
> >>>>>>>>>>>>> prefix="cdvfile://localhost/temporary"
src="cache" />
> >>>>>>>>>>>>>      <filesystem name="persistent"
> >>> type="local-filesystem"
> >>>>>>>>>>>>> prefix="cdvfile://localhost/persistent"
src="Documents"
> >>> />
> >>>>>>>>>>>>>      <filesystem name="content"
> >>> type="content-filesystem"
> >>>>>>>>>>>>> prefix="content://" />
> >>>>>>>>>>>>>    </filesystems>
> >>>>>>>>>>>>>  </feature>
> >>>>>>>>>>>>> </widget>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> (The platform's defaults.xml, or
whatever we're calling
> >>> it
> >>>>>> these
> >>>>>>>>> days,
> >>>>>>>>>>>>> could specify the default mapping,
so that devs could
> >>> write
> >>>>>>>>>>>> cross-platform
> >>>>>>>>>>>>> apps without having to add this
for every platform, or
> >>> even
> >>>>> at
> >>>>>>> all,
> >>>>>>>>> if
> >>>>>>>>>>>> they
> >>>>>>>>>>>>> don't care to change it)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think that being this explicit
will let us change the
> >>> url
> >>>>>>> scheme
> >>>>>>>>> as
> >>>>>>>>>>>>> needed (hopefully cdvfile won't
need to change, but it
> >>>> would
> >>>>>> have
> >>>>>>>>> if it
> >>>>>>>>>>>> was
> >>>>>>>>>>>>> still "filesystem"). It could eventually
allow new FS
> >>>> plugins
> >>>>>> to
> >>>>>>> be
> >>>>>>>>>>> added
> >>>>>>>>>>>>> to an app with this mechanism. And
it would mean that we
> >>>>> could
> >>>>>>> roll
> >>>>>>>>>>> out a
> >>>>>>>>>>>>> default configuration that left
the iOS files in their
> >>>>> current
> >>>>>>>>>>> locations:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> <filesystem name="temporary"
> >>>>>>>>>>>>>    type="local-filesystem"
> >>>>>>>>>>>>>    prefix="cdvfile://localhost/temporary"
> >>>>>>>>>>>>>    src="Temporary" />
> >>>>>>>>>>>>> <filesystem name="persistent"
> >>>>>>>>>>>>>    type="local-filesystem"
> >>>>>>>>>>>>>    prefix="cdvfile://localhost/persistent"
> >>>>>>>>>>>>>    src="Documents" />
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> and then, in a later version, we
could change the default
> >>>> for
> >>>>>> new
> >>>>>>>>>>>> projects
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> <filesystem name="temporary"
> >>>>>>>>>>>>>    type="local-filesystem"
> >>>>>>>>>>>>>    prefix="cdvfile://localhost/temporary"
> >>>>>>>>>>>>>    src="Temporary" />
> >>>>>>>>>>>>> <filesystem name="persistent"
> >>>>>>>>>>>>>    type="local-filesystem"
> >>>>>>>>>>>>>    prefix="cdvfile://localhost/persistent"
> >>>>>>>>>>>>>    src="Library" />
> >>>>>>>>>>>>> <filesystem name="documents"
> >>>>>>>>>>>>>    type="local-filesystem"
> >>>>>>>>>>>>>    prefix="cdvfile://localhost/documents"
> >>>>>>>>>>>>>    src="Documents" />
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> and existing projects shouldn't
see any change. And in
> >>> the
> >>>>>>> meantime,
> >>>>>>>>>>> any
> >>>>>>>>>>>>> dev who wanted to use the more sensible
filesystem
> >>>> locations
> >>>>>>> could
> >>>>>>>>> just
> >>>>>>>>>>>>> change their own config.xml.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm going to take a stab at implementing
this as
> >>> described,
> >>>>> but
> >>>>>>>>>>>> discussion
> >>>>>>>>>>>>> is certainly welcome before it goes
out to the world. As
> >>>>>> multiple
> >>>>>>>>>>> people
> >>>>>>>>>>>>> have said, we need to get this right,
and not hurt all of
> >>>> our
> >>>>>>>>> existing
> >>>>>>>>>>>>> devs.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ian
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>

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