Good point Don, the requirements should be out of scope for a plugin developer. I agree that ultimately this is a choice that the developer should make for their own app.
@purplecabbage risingj.com On Wed, Apr 17, 2013 at 1:22 PM, Don Coleman <don.cole...@gmail.com> wrote: > On Windows Phone the permission required to access NFC is ID_CAP_PROXIMITY. > > The ID_REQ_NFC restricts the application to running on only devices that > have NFC. > > This would be equivalent to setting android:required to true for a feature > > <uses-feature android:name="android.hardware.nfc" > android:required="true" /> > > AFAIK android:required="true" only effects Google Play listings. > > Plugman should set the features and permissions. I think adding hardware > restrictions is a decision that needs to be made by the app developer. > > > On Wed, Apr 17, 2013 at 3:41 PM, Jesse <purplecabb...@gmail.com> wrote: > > > I could, or it could just be an ignored tag for other platforms. It will > > sit inside the platform tag anyway. > > could also just add an optional attrib to the permission tag : > > <permission type='requirement' name='ID_REQ_NFC' /> > > > > The names already do contain enough info to easily parse, ID_CAP_* > ID_REQ_* > > not to mention ID_RESOLUTION_* > > > > I am down with whatever. > > > > > > @purplecabbage > > risingj.com > > > > > > On Wed, Apr 17, 2013 at 12:24 PM, Filip Maj <f...@adobe.com> wrote: > > > > > Hmm, this could be an implementation detail for windows phone. > > > > > > Requirement vs permission isn't syntactically different. Could we > > > encapsulate Windows Phone requirements as <permission> elements in > > > plugin.xml, and have tooling be smart enough to parse wp7 + wp8 > > <platform> > > > <permission> elements and drop them into the Windows Phone manifest as > > > whatever elements they need to be? > > > > > > On 4/17/13 12:16 PM, "Jesse" <purplecabb...@gmail.com> wrote: > > > > > > >While we are there, we may want to add an optional requirements tag. > > > >Requirements let the app specify what device features it must have, > for > > > >example NFC. [1] > > > >Logically this would just fall right under platform, and be optional : > > > > > > > > <platform name="wp8"> > > > > <requirement name="ID_REQ_NFC" /> > > > > </platform> > > > > > > > >Does it make sense for us to group these? > > > >ie. > > > > > > > ><platform> > > > > <permissions> > > > > <permission/> > > > > ... > > > > </permissions> > > > > <requirements> > > > > <requirement/> > > > > ... > > > > </requirements> > > > ></platform> > > > > > > > > > > > > > > > > > > > >[1] > > > > > > > > > > http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/04/17/defining > > > >-your-app-s-requirements-for-a-great-customer-experience.aspx > > > > > > > > > > > > > > > >@purplecabbage > > > >risingj.com > > > > > > > > > > > >On Wed, Apr 17, 2013 at 12:04 PM, Filip Maj <f...@adobe.com> wrote: > > > > > > > >> Good call, sound rule of thumb > > > >> > > > >> On 4/17/13 12:03 PM, "Jesse" <purplecabb...@gmail.com> wrote: > > > >> > > > >> >RE: the permission element > > > >> >Looks good for wp7 + wp8 > > > >> >I assume if some platform requires extra data in the permission tag > > it > > > >>can > > > >> >have it, the same way that the blackberry version has the system > > > >> >attribute. > > > >> > > > > >> >@purplecabbage > > > >> >risingj.com > > > >> > > > > >> > > > > >> >On Wed, Apr 17, 2013 at 11:48 AM, Jeffrey Heifetz > > > >> ><jheif...@blackberry.com>wrote: > > > >> > > > > >> >> Makes sense to me. > > > >> >> > > > >> >> Sent from my BlackBerry 10 smartphone on the Rogers network. > > > >> >> From: Filip Maj > > > >> >> Sent: Wednesday, April 17, 2013 2:43 PM > > > >> >> To: dev@cordova.apache.org > > > >> >> Reply To: dev@cordova.apache.org > > > >> >> Subject: Re: plugman + plugin spec final q's > > > >> >> > > > >> >> > > > >> >> K one more update: <permission> element that will be a child of > > > >> >><platform> > > > >> >> elements. > > > >> >> > > > >> >> Examples: > > > >> >> <platform name="android"> > > > >> >> <permission name="android.permission.INTERNET" /> > > > >> >> </platform> > > > >> >> <platform name="blackberry"> > > > >> >> <permission name="_sys_use_consumer_push" system="true" /> > > > >> >> </platform> > > > >> >> <platform name="wp7"> > > > >> >> <permission name="ID_CAP_CONTACTS" /> > > > >> >> </platform> > > > >> >> > > > >> >> > > > >> >> `name` attribute is mandatory, mapping to native strings > > representing > > > >> >> specific features/permissions. > > > >> >> > > > >> >> `system` attribute is optional and false by default. Only used by > > > >> >> BlackBerry for certain system-level permissions. > > > >> >> > > > >> >> I think this satisfies our use cases. > > > >> >> > > > >> >> Thoughts/comments welcome. > > > >> >> > > > >> >> > > > >> >> > > > >> >> On 4/17/13 11:07 AM, "Jeffrey Heifetz" <jheif...@blackberry.com> > > > >>wrote: > > > >> >> > > > >> >> >I was thinking exactly along the same lines as Braden. Whatever > > > >> >>universe > > > >> >> >the cordova core plugins live in will likely be default, with > the > > > >>wild > > > >> >> >west following it. SO long as plugman is explicit about where it > > is > > > >> >> >fetching from, a dev shouldn't have to find the URL and hope it > > > >>never > > > >> >> >changes. > > > >> >> > > > > >> >> >On 13-04-17 2:01 PM, "Braden Shepherdson" <bra...@chromium.org> > > > >>wrote: > > > >> >> > > > > >> >> >>I think there will be a common repo, where the Cordova core > > plugins > > > >> >>and > > > >> >> >>some others live. See the spec for the remotes.js file; I think > > it > > > >> >>should > > > >> >> >>search for plugins with the given name in each of those > > universes. > > > >> >> >>Specifying a url in the <dependency> would then only be > necessary > > > >>for > > > >> >> >>other > > > >> >> >>universes. > > > >> >> >> > > > >> >> >>Braden > > > >> >> >> > > > >> >> >> > > > >> >> >>On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <f...@adobe.com> > > wrote: > > > >> >> >> > > > >> >> >>> But then we'd need to be able to discover the different > > > >>universes.. > > > >> >> >>>Unless > > > >> >> >>> we all agree on a "default", don't think this is optional.. > > > >> >> >>> > > > >> >> >>> On 4/17/13 10:53 AM, "Jeffrey Heifetz" < > > jheif...@blackberry.com> > > > >> >> wrote: > > > >> >> >>> > > > >> >> >>> >Coming back to Braden's suggestion of specifying a url and > id > > > >>for > > > >> >> >>>plugin > > > >> >> >>> >dependency, I think this is the correct route, and would go > > > >> >>further to > > > >> >> >>> >suggest the url is optional. I do not believe we should > > > >>inherently > > > >> >>tie > > > >> >> >>> >plugin dependency to the exact source. Thats why we have a > > > >> >>discovery > > > >> >> >>> >system and multiple places to get a plugin from. > > > >> >> >>> > > > > >> >> >>> >On 13-04-17 1:37 PM, "Filip Maj" <f...@adobe.com> wrote: > > > >> >> >>> > > > > >> >> >>> >>Braden and I had a little chat on IRC about > install/uninstall > > > >>and > > > >> >> >>>calling > > > >> >> >>> >>prepare. We've agreed that having prepare as a separate > > > >>command is > > > >> >> >>>useful > > > >> >> >>> >>(you tweak some plugin JS files, add more JS files, and > want > > > >>that > > > >> >> >>> >>reflected in your app), but also calling prepare > > automatically > > > >> >>after > > > >> >> >>>an > > > >> >> >>> >>install and uninstall makes sense too (otherwise people > using > > > >> >>plugman > > > >> >> >>> >>will > > > >> >> >>> >>have to call prepare manually after calling install or > > > >>uninstall). > > > >> >> >>> >> > > > >> >> >>> >>FTR, --prepare composes the cordova_plugins.json object > that > > is > > > >> >>read > > > >> >> >>>by > > > >> >> >>> >>cordova.js and handles injecting plugin JS into the app. It > > > >>will > > > >> >>also > > > >> >> >>>be > > > >> >> >>> >>responsible for handling permissions that plugins require > and > > > >> >>setting > > > >> >> >>>up > > > >> >> >>> >>platform manifests appropriately based on all installed > > > >>plugins. > > > >> >> >>> >> > > > >> >> >>> >>On 4/17/13 10:25 AM, "Brian LeRoux" <b...@brian.io> wrote: > > > >> >> >>> >> > > > >> >> >>> >>>Braden: you thinking that the config is canonical and then > > > >> >>prepare > > > >> >> >>> >>>quietly > > > >> >> >>> >>>does the right thing based on that? > > > >> >> >>> >>> > > > >> >> >>> >>>(Agree less steps is exactly what we're going for here.) > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>>On Wed, Apr 17, 2013 at 10:16 AM, Braden Shepherdson > > > >> >> >>> >>><bra...@chromium.org>wrote: > > > >> >> >>> >>> > > > >> >> >>> >>>> Re: --install calling --prepare: no. It could, though, I > > > >> >>suppose. > > > >> >> >>> >>>> > > > >> >> >>> >>>> Why not have --prepare handle the plugins rather than > > > >> >> >>>install/remove. > > > >> >> >>> >>>>We're > > > >> >> >>> >>>> trying to make less, not more, happen at install time. > > > >>Someday > > > >> >>I > > > >> >> >>>hope > > > >> >> >>> >>>> --install ceases to exist. > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> On Wed, Apr 17, 2013 at 12:59 PM, Filip Maj < > > f...@adobe.com> > > > >> >> wrote: > > > >> >> >>> >>>> > > > >> >> >>> >>>> > Max, yeah, at the top of the plugman readme (in both > > > >>future > > > >> >>and > > > >> >> >>> >>>>master I > > > >> >> >>> >>>> > believe), the usage docs don't specify --install or > > > >> >>--uninstall > > > >> >> >>>as > > > >> >> >>> >>>>an > > > >> >> >>> >>>> > available command, but those commands are referenced > > right > > > >> >>after > > > >> >> >>>the > > > >> >> >>> >>>> usage > > > >> >> >>> >>>> > section. I'd be in favor of using --fetch for the > > > >>RETRIEVAL > > > >> >>of > > > >> >> >>> >>>>plugins, > > > >> >> >>> >>>> > --remove for the removal of plugins from the local > > plugins > > > >> >> >>>cache, > > > >> >> >>> >>>>and > > > >> >> >>> >>>> > --install and --uninstall for the relevant actions. > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > Max, re (2): correct. > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > To Braden's points: > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > - I'm fine with url + name attributes for <dependency> > > > >> >> >>>elements. > > > >> >> >>> >>>>Will > > > >> >> >>> >>>> > update the spec/README shortly. > > > >> >> >>> >>>> > - Re <clobbers> I will add a note about that to the > spec > > > >>as > > > >> >> >>>well. > > > >> >> >>> >>>> > - Re parsing package Ids, fair enough. > > > >> >> >>> >>>> > - About "namespacing" iOS source files, this sounds > > like a > > > >> >>good > > > >> >> >>> >>>>idea. > > > >> >> >>> >>>> > This is something that plugman can handle as well, > yes? > > > >>That > > > >> >>is, > > > >> >> >>> >>>> > management of the plist and pointing to the right > > > >>location. > > > >> >> >>> >>>> > - Re config munging and permissions. I vote in favor > of > > > >> >> >>>removing > > > >> >> >>> >>>>all > > > >> >> >>> >>>> > permissions and re-adding all of them with every > change > > in > > > >> >> >>>plugins > > > >> >> >>> >>>>(add > > > >> >> >>> >>>> or > > > >> >> >>> >>>> > remove), with a de-duping pass. Brute force approach > but > > > >> >>it'll > > > >> >> >>>work > > > >> >> >>> >>>>and > > > >> >> >>> >>>> is > > > >> >> >>> >>>> > simple. However spec wise we need a separate element > for > > > >>this > > > >> >> >>>ya? > > > >> >> >>> >>>> > <permission> or something? Then based on what > <platform> > > > >>tag > > > >> >> >>>houses > > > >> >> >>> >>>>a > > > >> >> >>> >>>> > <permissions> tag we can deduce where and how to set > up > > > >>the > > > >> >> >>> >>>>appropriate > > > >> >> >>> >>>> > native permissions. > > > >> >> >>> >>>> > - Re the different <*-file> elements. I believe > behavior > > > >>in > > > >> >>how > > > >> >> >>> >>>>header > > > >> >> >>> >>>> > and source files are handled on iOS are identical, so > > > >> >> >>>consolidating > > > >> >> >>> >>>>those > > > >> >> >>> >>>> > is an easy simplification. I will update the spec with > > > >>that. > > > >> >> >>>I'll > > > >> >> >>> >>>>leave > > > >> >> >>> >>>> > resource-file in there for now. > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > One more question that came up: does a plugman > --install > > > >>call > > > >> >> >>> >>>>implicitly > > > >> >> >>> >>>> > call plugman --prepare ? > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > On 4/17/13 9:31 AM, "Max Woghiren" <m...@chromium.org > > > > > >> wrote: > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > >(1) On line 25 of the cordova-plugman readme, is the > > > >>command > > > >> >> >>> >>>>missing > > > >> >> >>> >>>> (ie. > > > >> >> >>> >>>> > >--add or --install or whatever)? > > > >> >> >>> >>>> > > > > > >> >> >>> >>>> > >(2) Though two versions of a plugin are not allowed, > I > > > >>just > > > >> >> >>>want to > > > >> >> >>> >>>>make > > > >> >> >>> >>>> > >sure: there will be some kind of detection that it's > > > >>okay if > > > >> >> >>>the > > > >> >> >>> >>>> > >*same*version of a plugin has already been installed > > by a > > > >> >> >>>previous > > > >> >> >>> >>>> > >dependency, > > > >> >> >>> >>>> > >right? (For example, plugins A and B both depend on C > > > >>v1.0, > > > >> >>so > > > >> >> >>> >>>>plugman > > > >> >> >>> >>>> > >will determine that this is okay, whereas if A > depends > > > >>on C > > > >> >> >>>v1.0 > > > >> >> >>> >>>>and > > > >> >> >>> >>>>B > > > >> >> >>> >>>> > >depends on C v1.1, there'll be an error). > > > >> >> >>> >>>> > > > > > >> >> >>> >>>> > > > > > >> >> >>> >>>> > >On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj > > > >><f...@adobe.com> > > > >> >> >>>wrote: > > > >> >> >>> >>>> > > > > > >> >> >>> >>>> > >> Hey all, > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> I've done a review of the spec and updated it. > Check > > it > > > >> >>out > > > >> >> >>>at > > > >> >> >>> >>>>the > > > >> >> >>> >>>> > >>README > > > >> >> >>> >>>> > >> in the plugman repo's future branch [1]. I've added > > the > > > >> >>last > > > >> >> >>>bit > > > >> >> >>> >>>>to > > > >> >> >>> >>>> it: > > > >> >> >>> >>>> > >> <dependencies> and <dependency> elements. Here is > an > > > >> >>example: > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> <dependencies> > > > >> >> >>> >>>> > >> <dependency > > > >> >> >>> >>>> > >> > > > >> >> >>>url="http://plugins.cordova.io/com.facebook.plugin/plugin.xml > " > > > >> >> >>> /> > > > >> >> >>> >>>> > >> <dependency > > > >> >> >>> >>>> > >> > > > >> >> >>>url=" > http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"; > > > >> >> >>> >>>> > >> version="1.0.0" /> > > > >> >> >>> >>>> > >> </dependencies> > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> Dependencies are specified by providing a url and > > > >> >>optionally > > > >> >> >>>some > > > >> >> >>> >>>>way > > > >> >> >>> >>>> of > > > >> >> >>> >>>> > >> describing what version of the plugin you want. The > > > >>only > > > >> >> >>> >>>>constraint > > > >> >> >>> >>>> > >> imposed on plugin dependencies right now is only a > > > >>single > > > >> >> >>>version > > > >> >> >>> >>>>of a > > > >> >> >>> >>>> > >> plugin can be installed in an app at the same > time. I > > > >> >>think > > > >> >> >>>this > > > >> >> >>> >>>>is > > > >> >> >>> >>>> good > > > >> >> >>> >>>> > >> enough, but wanted to let everyone know and give > > people > > > >> >>time > > > >> >> >>>to > > > >> >> >>> >>>> comment. > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> Also did a bunch of updates/tweaks to the > plugin.xml > > > >>spec, > > > >> >> >>>made > > > >> >> >>> >>>> explicit > > > >> >> >>> >>>> > >> some failures (if there are file conflicts, error > > > >>noisily, > > > >> >> >>>that > > > >> >> >>> >>>>kind > > > >> >> >>> >>>> of > > > >> >> >>> >>>> > >> stuff). I have a PluginTooling [2] wiki article up > > > >>where > > > >> >>I am > > > >> >> >>> >>>>doing my > > > >> >> >>> >>>> > >> best to summarize these various reqs/use cases > > floating > > > >> >> >>>around > > > >> >> >>> >>>>the > > > >> >> >>> >>>> list, > > > >> >> >>> >>>> > >> IRC, hangout discussions regarding plugin tooling > > > >> >> >>>development. If > > > >> >> >>> >>>>you > > > >> >> >>> >>>> > >>have > > > >> >> >>> >>>> > >> anything to add there please do so! > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> Next, I have a few questions came up when I was > going > > > >> >>through > > > >> >> >>>the > > > >> >> >>> >>>> spec: > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> - does <clobbers> and <merges> (specified in the JS > > > >>symbol > > > >> >> >>> >>>>mapping > > > >> >> >>> >>>> > >> section of the plugin spec) create the objects on > > > >>window > > > >> >>if > > > >> >> >>>they > > > >> >> >>> >>>>do > > > >> >> >>> >>>> not > > > >> >> >>> >>>> > >> exist? I suppose this is more of a cordova.js > > question > > > >> >>than a > > > >> >> >>> >>>>spec > > > >> >> >>> >>>> > >> question, but that behavior should be explicit in > the > > > >> >>spec. > > > >> >> >>> >>>> > >> - native code <source-file> elements have a > `target` > > > >> >> >>>attribute > > > >> >> >>> >>>>where > > > >> >> >>> >>>> > >>you > > > >> >> >>> >>>> > >> specify where within the native project the native > > code > > > >> >> >>>should be > > > >> >> >>> >>>> copied > > > >> >> >>> >>>> > >> into. Is this necessary? For Java files, we could > > look > > > >>at > > > >> >>the > > > >> >> >>> >>>>package > > > >> >> >>> >>>> > >> declaration at the top to determine where to put > it. > > If > > > >> >>I'm > > > >> >> >>>not > > > >> >> >>> >>>> > >>mistaken, > > > >> >> >>> >>>> > >> on iOS it doesn't matter where within the directory > > > >> >>structure > > > >> >> >>>of > > > >> >> >>> >>>>a > > > >> >> >>> >>>> > >> cordova-ios project you put native code in. What is > > the > > > >> >> >>>situation > > > >> >> >>> >>>>for > > > >> >> >>> >>>> > >>the > > > >> >> >>> >>>> > >> Windows (Phone) platforms, and for cordova-osx? > > > >> >> >>> >>>> > >> - the spec currently only accounts for appending > XML > > to > > > >> >> >>>specific > > > >> >> >>> >>>> parts > > > >> >> >>> >>>> > >>of > > > >> >> >>> >>>> > >> XML-based configuration documents. Does anyone > > foresee > > > >>an > > > >> >> >>> >>>>instance > > > >> >> >>> >>>> where > > > >> >> >>> >>>> > >> some manner of native or cordova-specific config > > > >>munging > > > >> >> >>>OTHER > > > >> >> >>> >>>>than > > > >> >> >>> >>>> > >> appending would be necessary? Removal/modification > of > > > >> >> >>>existing > > > >> >> >>> >>>> elements? > > > >> >> >>> >>>> > >> - iOS specific: Do we need separate elements for > > > >> >> >>><source-file>, > > > >> >> >>> >>>> > >> <resource-file> and <header-file>? Can we > consolidate > > > >>into > > > >> >> >>>one? > > > >> >> >>> >>>>The > > > >> >> >>> >>>> > >> current draft of the spec mentions that this may be > > an > > > >> >> >>> >>>>implementation > > > >> >> >>> >>>> > >> detail. > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> Finally, I have two questions/concerns about the > > > >>command > > > >> >>line > > > >> >> >>> >>>> interface > > > >> >> >>> >>>> > >> for plugman. > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> 1. The --fetch operation seems to need a redundant > > > >> >>--plugin > > > >> >> >>>flag, > > > >> >> >>> >>>>e.g. > > > >> >> >>> >>>> > >> plugman --fetch --plugin <url>. Shouldn't we just > axe > > > >> >> >>>--plugin in > > > >> >> >>> >>>>this > > > >> >> >>> >>>> > >> case? > > > >> >> >>> >>>> > >> 2. The API readme mentions --install and > --uninstall > > > >>flags > > > >> >> >>>but > > > >> >> >>> >>>>the > > > >> >> >>> >>>> docs > > > >> >> >>> >>>> > >> only show --fetch and --remove. Can we clarify > this? > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> Thanks for everyone's input. I feel we're getting > > > >>closer > > > >> >>to > > > >> >> >>> >>>>shipping > > > >> >> >>> >>>> > >>this > > > >> >> >>> >>>> > >> thing! > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> [1] > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> > > > >> >> > > > >> > > https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlo > > > >> >> >>> >>>>g > > > >> >> >>> >>>> > ; > > > >> >> >>> >>>> > >>h= > > > >> >> >>> >>>> > >> refs/heads/future > > > >> >> >>> >>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > >> > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > > > > >> >> >>> >>>> > > > >> >> >>> >> > > > >> >> >>> > > > > >> >> >>> > > > > >> >> >>> > > > >> > > >>>--------------------------------------------------------------------- > > > >> >> >>> >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. > > > >> >> > > > >> > > > >> > > > > > > > > >
