royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: Proxy method calls with RemoteObject
Date Fri, 19 Oct 2018 17:31:18 GMT
Hi Alex,

I don't doubt you have reason, and take for sure that I want to be one more
person capable of contribute to compiler. Just think that I can't do so
many tasks in just few time:  I need to code an entire application, I have
to add missed things to Jewel that are still not done, correct and fix
components that are partially done, and I have just 2 months to do all of
this. For example, I still have to add year view to datechooser to make it
usable, add autocompletion bead for combobox to make it usable as well,
just to name two of many more things without I can go to production.

I'll get to know that things and hope some day to be able to contribute to
add TypeScript or WASM, but that should be progressive. We must to act we
some real plans and handle things with proper timing as any other business
if we want Royale to evolve and be considered as a real technology to use
for many people, or have a risk that we fail in our current goals, and hurt
the project in a way that put at risk the project itself.

I have in mind some steps to make our work get more progress, but we need
to help us each other to get each one part done so we reach a new level,
and make others to join us, and hopefully people with potential skills to
help in compiler, in framework, in design and visuals of components, and

Think that from other view, I try to have many skills: code, design,
art,...I can add compiler coding, but is not easy and very few people is
good in all disciplines at the same time.

El vie., 19 oct. 2018 a las 18:46, Alex Harui (<>)

> IMO, the project is at a greater risk if, when a bug is reported, there
> aren't several people volunteering to fix it because they don't have
> experience fixing certain kinds of issues.
> Why would you choose any framework if you couldn't get timely support?
> This is a great opportunity for someone else like yourself to get
> experience in js-release issues and help the project.
> My 2 cents,
> -Alex
> On 10/19/18, 2:39 AM, "Carlos Rovira" <> wrote:
>     Hi Alex
>     El jue., 18 oct. 2018 a las 18:51, Alex Harui
> (<>)
>     escribió:
>     > I did not realize source maps are gone. Please put them back in.
> There
>     > were useful at times.  I don't understand why they were removed.
> Can you
>     > summarize the discussion?
>     >
>     Ok, my perception was that source maps on release was a bug. Since Josh
>     developed that part I asked him, as he points in his responses the
> rest is
>     like he said.
>     I'll put it back again, since is clear that those are useful.
>     | Because you are essentially building out a new UI for a client, your
> work
>     is not overlapping with my goals as much.
>     I understand that you want to use your time as you want, but my opinion
>     about this concrete case is that you are investing your time in
> emulate MX
>     and SPARK, currently, I'm testing MX RO and reporting there's a bug
> that
>     makes MX applications doesn't work in release mode. My goals are only
> in MX
>     RO (that fails silently), but MX Application in release mode doesn't
> work
>     at all. As you say, the later is not in my goals and we don't overlap,
> but
>     MX RO seems to be in the intersection. I don't say you must work on
> that,
>     only say that I think in that concrete points we share same goals. At
> the
>     end, that problem will need to be addressed if you want MX/Spark
> emulation
>     be ready in release mode. In the other hand, I'll be glad to pay
> anyone to
>     knows how to fix this issue (even you if that is an option), since I
> think
>     it impact my Application, and after that, it impact us as Apache
> Royale,
>     since getting this App done, and sharing it, will impact in the people
>     reading from us and considering using Apache Royale.
>     Thanks
>     --
>     Carlos Rovira

Carlos Rovira

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