flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: [Royale] Flex to FlexJS migration path
Date Sat, 30 Sep 2017 00:00:13 GMT
Hmm..But I was in my mind something simple. If we just show the names -
without to much details - even Basic can landed onto that table. Once user
see names will be able to look himself into that.

Piotr

On Sat, Sep 30, 2017, 00:22 Alex Harui <aharui@adobe.com> wrote:

> IMO, we want to compare the Express and maybe MDL packages against Flex's
> Spark and MX.  Comparing Basic components will be too difficult because of
> how configurable they are.  And this might inspire us to create a
> Migration component set that is better tuned to ease migration.
>
> My 2 cents,
> -Alex
>
> On 9/29/17, 11:40 AM, "Peter Ent" <pent@adobe.com> wrote:
>
> >Hi,
> >
> >I'm moving to discussion over to Royale, but still including users from
> >flex who have not yet subscribed to the new Royale email lists.
> >
> >I was speaking with Alex earlier and we thought the idea of a comparison
> >table was a good one. I've been giving some thought to what this might
> >look like and how complex it should (and it could) be.
> >
> >Take for example, Panel. Both Flex and Royale have a Panel. There are some
> >differences and, being a developer myself, I'd like at least a quick
> >comparison so I would know how to convert any uses of Panel such as MXML
> >attribute differences and such.
> >
> >Using TextInput as another example, the Royale TextInput has far few
> >options, but things like password security can be added as beads.
> >
> >We were also thinking of an app that would dive into the ASDocs and
> >present a side-by-side, where possible, comparison. That would be a bit of
> >a project.
> >
> >Please share your thoughts.
> >
> >Regards,
> >Peter Ent
> >Adobe Systems/Apache Royale Project
> >
> >On 9/28/17, 6:43 PM, "Idylog - Nicolas Granon" <ngranon@idylog.com>
> wrote:
> >
> >>Many thanks for your comments and thoughts,
> >>
> >>(this thread is a follow-up of "[FlexJS] Guidelines for implementation of
> >>layout containers and navigation containers" but I felt that the topic
> >>was getting more general).
> >>
> >>(May I remind to the readers that my company is not very interested in
> >>keeping a "dual output" (SWF/JS) from FlexJS. We believe that FlexJS
> >>should concentrate on outputting JS, and JS only, from AS3 and MXML code.
> >>We also believe that MXML/AS3 project directed to AIR should stay under
> >>the Flex umbrella (not FlexJS). It is however interesting if library
> >>(modules/SWC) project can have dual output, but it is not mandatory. Our
> >>opinions do not reflect all the use-cases of the Flex community! We will
> >>be happy to hear from other people and differing opinions).
> >>
> >>I have to say that it is really a pleasure to have that kind of
> >>discussion and that your height of view is quite amazing (I'm not sure
> >>that "height of view" is a correct English expression ??? Please excuse
> >>my bad English).
> >>
> >>We, at Idylog - and others - have obviously strong calendar constraints.
> >>We can expect a real decrease in Flash Player support from browser
> >>editors in the next 12 months, well before Adobe end of support.
> >>
> >>Add to that all the apple-fan crowd (and others) being so happy that
> >>Flash Player is - at last - sent to the grave (I have read such papers).
> >>And all the people who do not even know that Flex exists, is based on FP,
> >>and is used for day to day operations in hundreds (thousands ?) of
> >>companies but are sooo happy that FP will finally disappear..
> >>
> >>I am pretty sure that running FP on our customers' workstations will be
> >>_very_ problematic well before Dec. 2020.
> >>
> >>In my company alone (and it's a tiny company!) two of my customers have
> >>already shown signs of nervousness. And every time there is a small
> >>glitch in one of our software, I immediately receive a call like "We had
> >>this problem because FP is over and your are keeping us in obsolete
> >>technology" !! No kidding.
> >>
> >>That said, I am a big fan of Flex (and FlexJS) and AS3.
> >>I believe that the fact that the language is *less* permissive and *less*
> >>flexible than JS is in fact a very good thing for the kind of software
> >>that we, at IdyLog, develop.
> >>
> >>But, to quote a popular series, "we are running out of time".
> >>
> >>I fully understand that you value "independence from layers of
> >>management". I understand that you want to give power of decision to
> >>everyone. It is a great and noble goal.
> >>And I fully support it in the domains of education, civil rights, freedom
> >>of thought/speech, criticism, politics, artistic creativity, academic
> >>research... everything intellectual and/or related to personal life but
> >>away from economic/profits concerns.
> >>
> >>The reality of my kind of company is : can I deliver an operational,
> >>functional, reliable, cheap solution in 5 weeks from scratch ? (or, as an
> >>architect, since we like to think about us as "digital architects" : can
> >>I have this house build in 12 months from scratch and under budget ? And
> >>we are not talking about building the next Chicago Art Museum ! Just an
> >>ordinary house !). That is why we cannot live without a reliable "faucet
> >>catalog" (and windows, and doors, and stairs and ready-to-use concrete
> >>formula and tiles etc.).
> >>
> >>We try to think "craftsmen" when we are in the conception phase, and
> >>think "industrial" when building the software (ever heard of "maintenance
> >>fees" from an architect ? Not me !).
> >>
> >>I would be quite happy if FlexJS could provide us with a reliable
> >>migration path (especially regarding UI components).
> >>
> >>As an example, it would be VERY useful to have a table showing, for each
> >>class from Flex SDK (that's a lot !),
> >>- the corresponding flexJS class if any (same API, same functionality,
> >>the class name might be identical or different)
> >>- if no corresponding class, the equivalent FlexJS class (with a detailed
> >>enumeration of differences between the two, plus examples, and for each
> >>strand, all the available beads)
> >>- if no equivalent, a suggested best-fit equivalent from an existing
> >>third-party JS library (with a short enumeration of differences)
> >>- if none of the above is available, a suggestion on how an equivalent
> >>class could be constructed (inheritance/composition clues)
> >>- the Flex SDK version number of the original class + link to reference
> >>docs
> >>- the FlexJS SDK version number of the target class + link to reference
> >>docs
> >>
> >>(I wrote "class", it obviously applies to interfaces too).
> >>
> >>For each FlexJS "equivalent" class, it should read :
> >>- whether the equivalent is JS only, or JS/SWF, or SWF only
> >>
> >>Such a document would be a great help in migration.
> >>
> >>Best regards,
> >>
> >>Nicolas Granon
> >>
> >>
> >>
> >>
> >>> -----Message d'origine-----
> >>> De : Alex Harui [mailto:aharui@adobe.com.INVALID]
> >>> Envoyé : jeudi 28 septembre 2017 22:32
> >>> À : users@flex.apache.org; ngranon@idylog.com
> >>> Objet : Re: [FlexJS] Guidelines for implementation of layout containers
> >>> and navigation containers
> >>>
> >>> Hi Nicolas,
> >>>
> >>> The Application developer is not required to use composition.  They are
> >>> most welcome to use inheritance just like in regular Flex and in fact,
> >>> the MXML component workflow is the same as regular Flex and based on
> >>> inheritance.
> >>>
> >>> You are correct about the Faucet analogy.  Faucet developers are
> >>> Component developers in FlexJS are are encouraged to compose new
> >>> faucets out of different smaller pieces (choose a metal, choose a
> >>> handle, choose pipe size).  What we don't have is a shopping catalog of
> >>> faucets (popular
> >>> components) mainly because we are too new to have any metrics about
> >>> popularity.  If you choose FlexJS you will be one of our first
> >>> reviewers.
> >>>
> >>> For sure, React has much better support right now because it has the
> >>> money to pay people to do it.  Apache projects are volunteer/community
> >>> driven, not corporation driven, and in our case we don't have the money
> >>> and need folks to pitch in.  In return for pitching in, you get more
> >>> control.  You get to have the bugs fixed you need fixed if you know how
> >>> to fix them, no layers of management in your way.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 9/28/17, 12:43 PM, "Idylog - Nicolas Granon" <ngranon@idylog.com>
> >>> wrote:
> >>>
> >>> >Hi Piotr,
> >>> >
> >>> >Many thanks for your help.
> >>> >
> >>> >We are not interested *at all* in SWF compatibility or alignment
> >>> >between a SWF and a JS version.
> >>> >Our goal is to migrate our browser-based applications catalog out of
> >>> >Flash player. We will keep AIR apps (desktop/mobile) under the
> >>> Flex/AIR
> >>> >hood. Common libraries (which usually do not have any UI) will be
> >>> >upgraded to mixed-mode when necessary (and if possible ! If not
> >>> >possible
> >>> >- or too complicated - we will have two versions, of for SWF, and one
> >>> >for JS).
> >>> >
> >>> >So maybe our best bet is to work on the integration of existing JS-
> >>> only
> >>> >UI components... (MDL, jQuery etc.)
> >>> >
> >>> >It would be nice if we had some clues about which JS UI library (or
> >>> >libraries) would be the closest to Flex-SWF components in terms of
> >>> >functionalities.
> >>> >
> >>> >(we would not like to have to pick from half a dozen different
> >>> >libraries ! We like things simple and powerful !).
> >>> >
> >>> >We found Sensha UI libraries very nice, but wayyyy too expensive (but
> >>> >we do not mind paying a reasonable license price).
> >>> >
> >>> >We develop only enterprise management software (no games, no
> >>> "personal"
> >>> >utilities) and the components that we use the most are Datagrid,
> >>> >HierarchicalDatagrid (very important), Forms (FormItem etc.),
> >>> >Validators (and custom validators), DropdownList... I will not
> >>> >enumerate all of them but you understand our needs... Localization is
> >>> >also very important to us
> >>> >(ResourceManager) and also quick and flexible layout management (but
> >>> we
> >>> >never use "custom" layouts).
> >>> >On the other hand, visual skinning is not the most important thing.
In
> >>> >our world, the most important thing is reliability, performance, and
> >>> >ease of use. Cosmetics comes at the bottom of our wishlist (even if
it
> >>> >is somehow related to ease of use).
> >>> >
> >>> >Another problem we face (for custom components) is dealing with
> >>> >composition vs inheritance.
> >>> >The concept is *intellectually* cleaner. No doubt about this.
> >>> >But for the conceptors/implementors, what was initially very simple
> >>> >(find the closest existing component, extend it, override what you
> >>> need
> >>> >to, add missing parts) suddenly becomes very very complicated because
> >>> >you have to guess what are the existing parts you should assemble
> >>> >(compose) among the hundreds of existing parts...(some of them already
> >>> >composed...!). In the "classic" Flex world, component compositing was
> >>> >used for...composed components ! (components with multiple functional
> >>> >"areas")  Not for standalone components.
> >>> >We feel like a contractor building a house, who needs to install and
> >>> >tweak a faucet, and instead of having to choose between four "kind"
of
> >>> >faucets we suddenly have to imagine and assemble a never-seen-before
> >>> >faucet by choosing between all possible kinds of pipes, all possible
> >>> >kinds of rubber, all possible kinds of metal, all possible kinds of
> >>> >knobs...
> >>> >
> >>> >I would like to say that our job is not to *build* tools but to
> >>> >*choose* tools in order to build usable software solutions. We are
> >>> >"house contractors", not "faucet contractors". We need a "faucet
> >>> >catalog" (UI
> >>> >library) with well defined characteristics. If necessary, we can
> >>> >slightly tweak it (custom item renderer is the most common need).
> >>> >
> >>> >Meanwhile, we are also testing ReactJS (although not a real framework
> >>> >but, again, our main issue is the UI part) and I must say that
> >>> >documentation, samples, contribution and community activity is very
> >>> >impressive...(not event talking about robustness and performance). At
> >>> >some point, rewriting our business logic in TypeScript (yes, we are
> >>> >testing with TypeScript because we want to stick to strongly typed
> >>> >code, classes...etc... and it works surprisingly well) might prove
> >>> more
> >>> >reliable, and not necessary more expensive... I personally prefers AS3
> >>> >over TypeScript (easier to read, no "fancy" syntax, cleaner handling
> >>> of
> >>> >"this"...) but TS is not bad at all.
> >>> >
> >>> >But we are going on in our tests and give a try to MDL (or another)
+
> >>> >flexJS.
> >>> >
> >>> >Best regards,
> >>> >
> >>> >Nicolas Granon
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >> -----Message d'origine-----
> >>> >> De : Piotr Zarzycki [mailto:piotrzarzycki21@gmail.com]
> >>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : users@flex.apache.org
> >>> >> Objet : Re: [FlexJS] Guidelines for implementation of layout
> >>> >> containers and navigation containers
> >>> >>
> >>> >> Hi Nicolas,
> >>> >>
> >>> >> I believe my answer will only partially satisfy you. About
> >>> containers
> >>> >> exists in FlexJS (Royale) you can read more here [1]. I would
> >>> >> strongly suggest look first on our examples [2]. We do not have
> >>> >> ViewStack container, so I believe that is something which can be
> >>> >> implemented and maybe pushed to our repository. We definitely suffer
> >>> >> for a lack of documentation, when I was started to dig into the
> >>> >> framework I simply look into how actually each component is
> >>> >> implemented [3] - architecture is pretty clean in my opinion and
> >>> more
> >>> >> composition oriented than inheritance. Quite helpful can be this
> >>> >> website [4] - That is the slight description about our main
> >>> principle PAYG.
> >>> >>
> >>> >> As for the components itself there are module Basic [3] which
> >>> >> contains our native components which should look same in SWF and
JS,
> >>> >> but as you probably know it is not fully true and not necessary
> >>> should be.
> >>> >>
> >>> >> There is also module MDL [5][6][7][8] which is wrapper around
> >>> >> existing components + some implementation of some additional things
> >>> >> like "dataProvider" in List. Encourage you to look into the code
of
> >>> >> components as I suggested it for Basic. This module do not have
SWF
> >>> >> representation - it is simply compile to JS only.
> >>> >>
> >>> >>  I hope we will be better and better with documentation and some
day
> >>> >> new users will not have to dig into the code. I can say also from
my
> >>> >> experience that once you will figure out how everything is working
> >>> >> productivity is quite good.
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>> a
> >>> >>ta=
> >>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
> >>> 2
> >>> >>c17
> >>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
> >>> A
> >>> >>q88
> >>> >>7xFTPSj2DuB%2B0%3D&reserved=0
> >>> >> es+and+Layouts
> >>> >> [2]
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
> >>> >>%7C
> >>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >>> d
> >>> >>ece
> >>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
> >>> B
> >>> >>t1Y
> >>> >>YMHGPVL7jA%3D&reserved=0
> >>> >> [3]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >>
> >>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
> >>> f
> >>> >>l
> >>> >> ex/html
> >>> >> [4]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>> a
> >>> >>=02
> >>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
> >>> 1
> >>> >>78d
> >>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
> >>> L
> >>> >>8KG
> >>> >>N7kM0uCu2z4%3D&reserved=0
> >>> >> 28
> >>> >> [5]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >>
> >>> >>asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/fle
> >>> x
> >>> >>/
> >>> >> org/apache/flex/mdl
> >>> >> [6]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >> asjs/tree/develop/examples/flexjs/MDLExample
> >>> >> [7]
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
> >>> d
> >>> >>l.i
> >>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
> >>> 5
> >>> >>06a
> >>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
> >>> &
> >>> >>sda
> >>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
> >>> >> [8]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>> =
> >>> >>02%
> >>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
> >>> 7
> >>> >>8de
> >>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
> >>> D
> >>> >>Lai
> >>> >>3UM8LpiO7APc%3D&reserved=0
> >>> >>
> >>> >> Thanks, Piotr
> >>> >>
> >>> >>
> >>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
> >>> >> <ngranon@idylog.com>:
> >>> >>
> >>> >> > We need to « re-implement » a ViewStack container component
class
> >>> >> > for use in a FlexJS (test) project.
> >>> >> >
> >>> >> > Is there a general walkthrough explaining (in details) the
> >>> >> > principles when creating a container component for FlexJS
(we are
> >>> >> > mostly interested in the js output, not SWF).
> >>> >> >
> >>> >> > We have read the docs at
> >>> >> >
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>> 2
> >>> >>%7C
> >>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >>> d
> >>> >>ece
> >>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
> >>> u
> >>> >>tx5
> >>> >>PB%2Btmt94%3D&reserved=0
> >>> >> > but it is rather control-oriented  (textInput, SliderŠ).
> >>> >> >
> >>> >> > We also plan to have TabNavigator etc. but I believe that
we can
> >>> >> > recreate a ViewStack container, creating other containers
won¹t be
> >>> >> > so
> >>> >> difficult.
> >>> >> >
> >>> >> > Also, is there some document around explaining how to implement
> >>> >> layout
> >>> >> > containers ? (as opposed to navigation containers).
> >>> >> >
> >>> >> > Or maybe we do not have the correct approach and reimplementing
MX
> >>> >> > components does not fit in the ³FlexJS² philosophy ?
> >>> >> >
> >>> >> > Many thanks in advance
> >>> >> >
> >>> >> > Nicolas Granon
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Piotr Zarzycki
> >>> >>
> >>> >> mobile: +48 880 859 557
> >>> >> skype: zarzycki10
> >>> >>
> >>> >> LinkedIn:
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.l
> >>> i
> >>> >>nke
> >>> >>din.com
> %2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a
> >>> 9
> >>> >>268
> >>> >>8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sda
> >>> t
> >>> >>a=S
> >>> >>ggb%2FVIn%2B0dBskPJ%2BZfJtXnRRrATLh1SHlamyGV58zM%3D&reserved=0
> >>> >>
> >>> >><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl
> .
> >>> l
> >>> >>ink
> >>> >>edin.com%2Fin%2Fpiotr-zarzycki-
> >>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>> >>4a9
> >>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
> >>> 2
> >>> >>459
> >>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
> >>> v
> >>> >>ed=
> >>> >>0>
> >>> >>
> >>> >> GitHub:
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> 8
> >>> >>8%7
> >>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
> >>> l
> >>> >>Mum
> >>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
> >>> >
> >>
> >>
> >
>
>

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