Hi 2018-05-29 16:00 GMT+02:00 Harbs <harbs.li...@gmail.com>: > > > 1. How do we define what is “Core"? >
*Core*: This classes are needed to build a Royale Application. All pieces here are required. No CSS is present here to wire any concrete relationship between pieces, as well avoiding possible inclussions of CSS rules and/or bugs in a final App. > 2. Should package names match the project names? > Normaly this is true always. Don't recall libraries with mixed package names. Some exceptions: Network has "net", but this is normal for less verbosity. > 3. Do we care to try and make package names shorter (i..e limit the level > of folders)? > Yes, if we can, but in the case os beads, since we'll be using mostly on mxml, we put shorter class name over package levels. Even on AS3 in this case is better a longer import than multiple longer class names use. > 4. What are the advantages and disadvantages of making Basic a dependency > for other component sets? > I think this is mostly explained here, and a image use to be better than thousand words, but the image mix graphs and explanations: https://snag.gy/DbH4iG.jpg > 5. A question which might follow the ones above are whether we should add > a new package. I’d rather wait to discuss this until we have some clarity > on the ones above. > mmm...you mean to say "package" or new "library" (maybe you refer to "Foundation" here) > > Can you think of any other questions we should be asking ourselves? > Not for now. Thanks Carlos > > Thanks, > Harbs > > > On May 29, 2018, at 4:41 PM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > Hi, > > > > completely. > > > > two things: > > > > 1. I propose in the new Discussion thread to make that work myself, but > we > > can do together. I think the best way is to rename and move things in > > chunks so we make this in various steps, testing builds not break, and so > > on....this will take some days to reach a good shape. > > 2. I already said my work was totally incomplete. But as we need this > > discussion I didn't do more but fixing build. > > > > > > 2018-05-29 15:13 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >> > >>> First, the hopefully easy things we can agree on: > >>> -I have no objection to dropping "Bead" off of bead class names > >>> -I have no objection to moving all views into a view subfolder as long > >> as nobody else is concerned about the size and performance issues. > >>> -I have no objection to moving classes in Basic that are > >> org.apache.royale.html to org.apache.royale.basic. > >>> -I have no objection to doing a massive rename and long as it isn't me > >> doing the work. > >>> -Whatever is in Core and Basic now or before Carlos's started moving > >> things around is not perfect. > >> > >> I agree with this completely. Carlos, do you agree as well? (I would be > >> willing to help out with a rename, but I want to make sure it doesn't > cause > >> too much disruption. > >> > >> Thanks, > >> Harbs > >> > >>> On May 23, 2018, at 12:43 AM, Alex Harui <aha...@adobe.com.INVALID> > >> wrote: > >>> > >>> Hi Carlos, > >>> > >>> I guess I don't understand why separating beads from TLCs is better. > >> How will that make things better for users or other component set > >> developers? That would effectively double the number of SWCs and each > TLC > >> SWC will need its bead SWC. That doesn't sound like a good thing to me, > >> but if that's what other folks want to do, that's fine with me. > >>> > >>> I was just looking through the classes in Jewel. It looks like JeweL > >> doesn't have a DataGrid yet.. When it does, I would think you will > want to > >> use the DataGridModel from Express as it handles both Arrays and > >> ICollectionViews. We will probably create a similar model bead that > takes > >> both ICollectionViews and Arrays for Lists and put that in Express as > >> well. Then we might decide that is better for Jewel to use that model > >> instead. Or maybe we'll decide to create a JewelExpress set that has > those > >> more general models that don't require as much configuration. Anyway, I > >> hope you agree that at some point, these more general models will be > used > >> by Express and some flavor of Jewel. I don't think this general model > >> should go in Core, or Basic (or some new category called Foundation). > And > >> at that point, Jewel or JewelExpress is going to re-use that code in > >> Express. > >>> > >>> Component sets are encouraged to re-use existing code from any other > SWC > >> since I think we've agreed that re-use is important. > >>> > >>> My 2 cents, > >>> -Alex > >>> > >>> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com <mailto: > >> carlos.rov...@gmail.com> on behalf of Carlos Rovira" < > >> carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com> on behalf of > >> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote: > >>> > >>> Hi Alex > >>> > >>> what do you think about separating the part in Basic that is > >> inherently the > >>> same as in Jewel (Button, CheckBox, TextInput, List, ...) along with > >> CSS > >>> that wire the beads for Basic UI set, and left the fundamental > >> building > >>> blocks as something that is not Core but can be reused by Basic and > >> Jewel > >>> (Let's call this "Foundation" Lib, I even like this name for this > >> library). > >>> > >>> I mean that having "Foundation" lib and "Basic" lib, will be more > >> clear, > >>> since we can expect what is in Basic will be never reused to build > >> other UI > >>> Sets (MDL, or others can still hang from there or if someone wants to > >> take > >>> the time refactor it). > >>> > >>> Foundation will not have any CSS wiring beads. We can return classes > >> from > >>> Core to Foundation. > >>> > >>> Basic will have its own CSS wiring beads, the same for Jewel. Both > >> will > >>> requiere Core and Foundation. > >>> > >>> I assume this will make all of us happy. > >>> > >>> We can as well do the package name changes to ensure consistency > >> along all > >>> code and libraries. > >>> > >>> Let me know what do you think > >>> > >>> thanks > >>> > >>> Carlos > >>> > >>> > >>> 2018-05-21 19:38 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > >>> > >>>> I understand this isn't the latest post on this thread, but it is the > >>>> easiest one for me to reply to: > >>>> > >>>> First, the hopefully easy things we can agree on: > >>>> -I have no objection to dropping "Bead" off of bead class names > >>>> -I have no objection to moving all views into a view subfolder as long > >> as > >>>> nobody else is concerned about the size and performance issues. > >>>> -I have no objection to moving classes in Basic that are > >>>> org.apache.royale.html to org.apache.royale.basic. > >>>> -I have no objection to doing a massive rename and long as it isn't me > >>>> doing the work. > >>>> -Whatever is in Core and Basic now or before Carlos's started moving > >>>> things around is not perfect. > >>>> > >>>> Now for the less easy. Regarding Core vs Basic, I see it this way: > >> Basic > >>>> is the simplest implementation of the constructs/concepts in Royale. > >> It is > >>>> intended to be extended and enhanced by other component sets via our > >> PAYG > >>>> principles. Core is intended to identify the constructs/concepts and > >> their > >>>> fundamental contracts. > >>>> > >>>> Think of it this way: When you open any class in Royale, you will > want > >> to > >>>> know what kind of class it is. It is a TLC, a Bead? And what kind of > >> TLC > >>>> or Bead? Is it View, Model, Controller? An ItemRenderer? These are > >> the > >>>> categories of classes we had, even in Flex. I've probably left out a > >> few > >>>> categories. It is the interfaces for these categories that go in > Core. > >>>> And maybe some classes we think are universal implementations of those > >>>> categories. And some beads that are component set agnostic, like > >>>> BrowserResizeHandler, although we could move those to another SWC and > >> say > >>>> that Core should not have any MXML components except maybe State. > >>>> > >>>> After any rename/refactor we decide on, Basic should still have some > >>>> interfaces because those interfaces describe the contract required for > >> the > >>>> simplest implementation. I get that it can be a fine line between > >>>> "fundamental" and "simplest", but where many classes that were in > Basic > >> get > >>>> away from "fundamental" is mainly around Containers. The way we > handle > >>>> Containers in Basic really seems like an opinion instead of a > universal, > >>>> "everyone must implement Containers this way" sort of thing. So it > does > >>>> not seem right that lots of Container-related things were moved to > Core. > >>>> > >>>> I thought we had agreement on the Terminology and Concepts thread that > >>>> re-usable pieces would be organized into multiple SWCs like Apache or > >> AS3 > >>>> Commons. Any component set designer gets to choose what SWCs to > borrow > >>>> from. The emulation SWCs may borrow from Express because they want to > >>>> re-use multi-purpose beads and aren't interested in the smallest, > >> fastest, > >>>> implementation. Assuming we fix any issues with accidentally > dragging > >> in > >>>> classes that aren't used, if you can re-use code from some other group > >> of > >>>> classes in another SWC, just do it. But do it because you "want to". > >>>> There is no "need to". The implementers should "want" to re-use code > >> when > >>>> possible. > >>>> > >>>> In the end, many component sets will re-use Basic beads. Maybe even > >>>> transitively because they re-use Express which re-uses Basic. That > >> should > >>>> be ok. That doesn't make it Core. It just that lots of component > sets > >>>> will start from simple implementations and add more complex > >> functionality. > >>>> The goal is to minimize code size and maximize performance by re-using > >>>> code. And as I thought we had agreed upon in Terminology and > Concepts, > >> we > >>>> should not be afraid to re-use code. We are asking our users to do > >> exactly > >>>> the same. We must create testing infrastructure and have review > periods > >>>> and other processes so we don't break downstream component sets or our > >>>> users applications. > >>>> > >>>> One related tidbit: IMO, the way folks will know what beads work with > >>>> what components will be done by identifying what interfaces the beads > >>>> implement, but also, I expected that we would use ASDoc as well. If > you > >>>> rummage through the source, you'll see that I annotated a few classes > >> with > >>>> @viewbead and @toplevel. We could add more. And because our ASDoc is > >> an > >>>> app, we can then apply smarter filtering that help folks narrow down > >> what > >>>> their choices are, similar to many of the online shopping filters I > see. > >>>> > >>>> My 2 cents, > >>>> -Alex > >>>> > >>>> > >>>> On 5/21/18, 3:53 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >>>> > >>>> Thank you for this. > >>>> > >>>> There’s two groups of files that were changed: Interfaces and and > >>>> Classes. > >>>> > >>>> In general, I would be more inclined to move interfaces than > classes, > >>>> but there are some things to consider: > >>>> > >>>> 1. There are still 17 interfaces in Basic. If the 5 that were moved > >>>> belong in Core, what about the remaining 17? > >>>> 2. I don’t think we’ve come to an agreement on what belongs in Core > >>>> and what belongs in Basic. > >>>> 3. I’d like to some to an agreement on a package name pattern. What > >>>> defines something belonging to a “core” path as opposed to an “html” > >> path? > >>>> Some classes are in supportClasses and some had that removed from the > >> path. > >>>> What’s the logic? etc. > >>>> 4. How should different pieces (such as different bead types) be > >>>> defined in paths? (I don’t think we’re completely consistent today.) > >>>> > >>>> I think we are coming to a conclusion on the CSS issues that Jewel > >>>> brought up. I think the CSS problems can be solved no matter whether > we > >>>> move things between packages and no matter wether we change package > >> paths. > >>>> I think the question on reorganization needs to be discussed on its > own > >>>> right. Do you agree with that? > >>>> > >>>> First organization of packages: > >>>> To me, there are two primary questions related to Core vs. Basic: > >>>> 1. What is the defining criteria for something to belong in Core as > >>>> opposed to Basic? > >>>> 2. Is there an issue with one component set (i.e. Jewel) to rely on > >>>> another (i.e. Basic). > >>>> > >>>> To be clear: I do believe that there is likely some reorganization > >>>> appropriate, but I’m not clear on exactly what and how. > >>>> > >>>> Depending on the answers to these questions, we can have a number of > >>>> different courses of action. We might keep things very similar to how > >> they > >>>> are. We might move things from Basic to Core. We might split Basic > into > >> two > >>>> packages. Other options? > >>>> > >>>> Regarding package paths: I don’t think there’s a single “right” > >> answer > >>>> to that, but we do need to agree on a pattern that we all stick to. > >>>> Currently (even before any refactor) package paths feel like many are > >>>> haphazard, and I often have difficulty guessing what the path is for a > >>>> specific class. I also sometimes have difficulty guessing which > package > >> a > >>>> specific class belongs to. > >>>> > >>>> These are the high-level questions I have. > >>>> > >>>> Please allow me to focus on question #2. I find it easiest to > discuss > >>>> concrete examples, so I’m taking TextPrompt, but it’s just an example. > >>>> Basic has a TextPromptBead. Jewel has TextPrompt. The code of the two > >>>> classes are identical. I’m assuming TextPrompt was copied because > >>>> TextPromptBead does not belong in Core (something I agree with), and > you > >>>> did not want Jewel to have a dependency on Basic. So my question is > >>>> (assuming CSS and classes not used are not copied), what is wrong with > >>>> Jewel using the TextPromptBead in Basic? To me the advantage of using > >> the > >>>> Basic bead is that there’s no code duplication and that helps from a > >>>> development perspective (i.e. only a single place to fix bugs) and > from > >> a > >>>> perspective of code size in the resulting application (in case both > >> classes > >>>> are used somewhere). > >>>> > >>>> Harbs > >>>> > >>>>> On May 21, 2018, at 11:29 AM, Carlos Rovira <carlosrov...@apache.org > > > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> as we talked I take the time to make a list of package name changes. > >>>>> Finally 20 classes were changed from package. > >>>>> Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in > >>>> red the > >>>>> changes to better following) > >>>>> > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/MXMLBeadView.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /MXMLBeadView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/views/ContainerView.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html/beads/ContainerView.as. > >>>>> (1) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/views/DataContainerView.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html > >>>>> /beads/DataContainerView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/GroupView.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/GroupView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IBackgroundBead.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/ > >>>>> html/beads/IBackgroundBead.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IBorderBead.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/IBorderBead.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IDropDownListView.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html > >>>>> /beads/IDropDownListView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/IListView.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html/beads/IListView.as. > >>>>> (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/ITextFieldView.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/ > >>>>> html/beads/ITextFieldView.as (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/TextFieldViewBase.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html/beads/TextFieldViewBase.as > >>>>> (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/layouts/LayoutChangeNotifier.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/layouts/LayoutChangeNotifier.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/models/ArraySelectionModel.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/models/ArraySelectionModel.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/models/ViewportModel.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html > >>>>> /beads/models/ViewportModel.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/Border.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/ > >>>>> html/supportClasses/Border.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/ContainerContentArea.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html/supportClasses/ContainerContentArea.as. > >>>>> (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/DataGroup.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html/supportClasses/DataGroup.as > >>>>> > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/DataItemRenderer.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ > >>>>> supportClasses/DataItemRenderer.as (3) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/MXMLItemRenderer.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ > >>>>> supportClasses/MXMLItemRenderer.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/UIItemRendererBase.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ > >>>>> supportClasses/UIItemRendererBase.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/Viewport.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html > >>>>> /supportClasses/Viewport.as > >>>>> > >>>>> Some comments: > >>>>> > >>>>> (1) "views" should follow the same package structure we have with > >>>> other > >>>>> beads 8"models", "controllers"...) to be consistent. > >>>>> (2) should go to "core/beads/views" as well > >>>>> (3) item renderers that should normaly be used by final users could > >>>> go some > >>>>> kind of "itemRenderers" package, while base item redeemer classes > >>>> could go > >>>>> again to supportClasses. > >>>>> > >>>>> As Harbs said, if we agree in the change of packages, we should do > >>>> this > >>>>> well and perform some other changes that make all more consistent > >>>> though > >>>>> libraries. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Carlos > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >>>>> > >>>>>> Definitely a plan. > >>>>>> > >>>>>> My guess is that if we agree on changing package paths, there will > >>>> likely > >>>>>> be other classes that should be considered. > >>>>>> > >>>>>> My preference would be to have this discussion after we finish the > >>>> project > >>>>>> refactor discussion because I think it’s going to be related to the > >>>> outcome > >>>>>> of that. > >>>>>> > >>>>>> Either way, I don’t think discussion should hold up the 0.9.3 > >>>> release. > >>>>>> We’re already past due for a release. We want to “release early and > >>>> release > >>>>>> often”… ;-) > >>>>>> > >>>>>> Thanks, > >>>>>> Harbs > >>>>>> > >>>>>>> On May 17, 2018, at 12:07 PM, Carlos Rovira < > >>>> carlosrov...@apache.org> > >>>>>> wrote: > >>>>>>> > >>>>>>> Ok, > >>>>>>> > >>>>>>> what if: > >>>>>>> > >>>>>>> * I take the time to generate a list of classes with package name > >>>> changes > >>>>>>> * Make a thread with the list to expose it > >>>>>>> * Let's see from there if people can live with it (We'll call > >>>> people to > >>>>>>> express about this changes and could see if are or not dramatic to > >>>> them) > >>>>>>> > >>>>>>> Sounds this like a plan? > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2018-05-17 10:58 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >>>>>>> > >>>>>>>> Sure. Same here. > >>>>>>>> > >>>>>>>> But things are much more stable now. As we move closer to “1.0”, > >>>> I think > >>>>>>>> we should be more careful about breaking changes and documenting > >>>> them > >>>>>> when > >>>>>>>> we decide they are necessary. > >>>>>>>> > >>>>>>>> As far as these specific changes go: We haven’t even come to a > >>>>>> conclusion > >>>>>>>> on what (if any) package names should change yet, and including > >>>> those > >>>>>>>> changes in a release is premature. If we do change package names, > >>>> I’m of > >>>>>>>> the opinion that they should be decided on and all happen at once > >>>> to > >>>>>>>> minimize impact on end-users. > >>>>>>>> > >>>>>>>> Does that help clarify things? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Harbs > >>>>>>>> > >>>>>>>>> On May 17, 2018, at 11:49 AM, Justin Mclean < > >>>> jus...@classsoftware.com> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>>> We are at the point where people are using Royale in > >>>> production. While > >>>>>>>> we can make breaking changes if they are warranted, they should > >>>> be kept > >>>>>> to > >>>>>>>> an absolute minimum and be carefully considered and well > >>>> documented if > >>>>>> we > >>>>>>>> do. > >>>>>>>>> > >>>>>>>>> There has been many previous breaking changes that broke the > >>>>>> application > >>>>>>>> I was working on and some more major than this and cost me a lot > >>>> of > >>>>>> time to > >>>>>>>> fix. Until you make it version 1.0 I think people will expect > >>>> that some > >>>>>>>> things may break with a new version. So why should this be an > >>>> exception > >>>>>> to > >>>>>>>> what has happened before? Saying that however, what would be good > >>>> to > >>>>>> see is > >>>>>>>> to provide guidance to what users need to change so their app > >>>> works with > >>>>>>>> any changes / backward compatibility issues. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Justin > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Carlos Rovira > >>>>>>> https://na01.safelinks.protection.outlook.com/?url= > >>>> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4 > 0adobe.com% > >>>> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de > >>>> cee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAj > osfP3JsQDt > >>>> rkTp%2FcrETCLE4%3D&reserved=0 > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Carlos Rovira > >>>>> https://na01.safelinks.protection.outlook.com/?url= > >>>> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4 > 0adobe.com% > >>>> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de > >>>> cee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAj > osfP3JsQDt > >>>> rkTp%2FcrETCLE4%3D&reserved=0 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Carlos Rovira > >>> https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W% > >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0 <https://na01.safelinks. > >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% > >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W% > >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0> > >> > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
