Hook CppMicroService into Redtamarin

But as I said you should take a look at CppMicroService framework and hook it to redtamarin to have a modular dynamic redtamarin where people can build their own bundle and add external features without having to know redtamarin internals.

That might accelerate your plan to implement something like Native Extension in a big way… Cause OSGi is the perfect plugin system that exist.

I’m using an Actionscript version of CppMicroservice adapted for Flex and I’m maintaining the Apache Flex version of that Framework.

OK you are confusing many things, quickly (sorry don’t have time)

  • OSGi is an architecture to manage modular stuff
    Redtamarin will certainly not base its code on that, we are above it
    as: we provide the core tools and you can implement OSGi with it if you want/need it
  • CppMicroservice based out of OSGi want to do the same modular stuff but at the service level
    again Redtamarin will cetainly not do that but if you need/want to implement it
    you will have the tools to do it
    end of the day CppMicroservice use HTTP to communicate between different services
    and is way too much influenced by the OSGi architecture, that’s a lot of overhead to just do micro-services based on HTTP

there is nothing so special in OSGi that make things faster or easier, it is just a way to do modular architecture, it’s like dependency injection, you can build stuff on the concept: dependency injection, inversion of control etc. or you can reuse the same concepts and heavily depends on a framework (for ex: guice, or is it juice?) anyway … this had a strong dependency and it is absolutely out of question that we fuck up the core API and classes with such thing.

I’m not saying OSGi is bad but it does not has it place at the core of Redtamarin,
go look at PHP, Python, Perl, Ruby, C#/.NET, Java etc. and take a good hard look at their standard default library and you will not find OSGi at their core, you might find optional libraries in such language that do implement OSGi though.

Anyway, it like orange and apple, you can use OSGi if you want, be a big fan of it and think it is perfect, but when it come to core API stuff, OSGi has nothing to do here, in fact it would be a huge architectural mistake to implement it at this level.

You are totally wrong about OSGi communicating via HTTP. It is micro-services inside of the runtime with bundles. The HTTP part is only a web-server bundle that you can use to browse in your browser to look at the state of your runtime and to visualize which bundles, services are started or stopped. I don’t think you know much about OSGi and I can deduce it by your previous post. If you want to understand OSGi ask me I’m working with it more than 10 years and I’ve implemented my own version in Actionscript.

First of all if you understood an ounce about OSGi it will probably blow your mind but it’s ok every developer has its own dogmas. That’s the best technology available today and I’ve did my research about modular architecture. None of the trends of micro-services of today are real micro-services. Only OSGi can achieve micro-services inside the same program at the code execution level.

but when it come to core API stuff, OSGi has nothing to do here, in fact it would be a huge architectural mistake to implement it at this level.

You are totally biased in your statement because OSGi doesn’t need to have a static ground where it can be used for architecture purpose. You can use it at every level that’s why it is shining.

OSGi exists in Python, C++, C#, Java, etc… so again biased statement. And just to put the cherry on the cake the people from Oracle decided to split their monolithic Java API into modular part that one can choose what they want to use with the RFC from Jigsaw so yeah OSGi even inspired the big boys like Sun and Oracle.

That statement is a good sign that you are not above anything with your design decision. Mostly uninformed. But it is okay that’s typical @zwetan :smiley: I’m used to it…

You can’t be above anything if your mind is closed like the mind of a religious dogmatic
dude :smiley:

or under it, that’s not the problem

it does not work at the same level of implementation

if you need MVC for a project, you implement it or reuse a library implementing it
you certainly do not expect MVC to be part of the standard libraries

that’s why libraries exist to let people implement whatever they want on top of the core language API

or put another way you will want to keep/have RegExp and Date in the builtins
you do not want OSGi in the builtins

I’ll tell you men before you talk about a subject try to do some little stuff with it and if it is really like you imagined then you can toss it aside but don’t judge something if you didn’t put your finger in the muddy dirt first.

Your understanding and narrowed view of OSGi is what keeps you from enlightenment but that’s ok it is your way of approaching the unknown. It took me 2 years of intense study to dig what is OSGi and let me tell you it is a fucking huge paradigm shift.

See it like meditation when you become good at it your brain wires to the universe and you understand shits you didn’t even know existed.

All the statements you did about OSGi can destroy them one by one if you are only ready to take the red pill NEO. I’ve digged into the AVM2 code base and I saw a huge potential to hook OSGi with the AVM2. That would bring a dynamic AVM2 with new classes available in independant bundles to the Actionscript 3.0 side.

Just so that you connect with the reality… the whole Flash Platform is based on the OSGi model. Adobe AIR and Flex also are based on that model.

The whole RSLs principles and Loader are just plain OSGi Architecture.

usually micro-services are distributed over different servers
and they communicate over HTTP or sockets with JSON or whatever else format you decide about

the AVM2 runtime already have a logic and mechanism to manage “bundle”
that’s basically the Domain class (with Redtamarin) or the ApplicationDomain class (with Flash/AIR)
which are here to inherits or merge or isolate code definitions
eg. why once you define a String class in the anonymous package you can not redefine it later

it does not work like OSGi at all

That’s not my problem to understand OSGi, you can perfectly port or reuse your already written OSGi ActionScript library, Redtamarin do not prevent that.

Now, that said, trying to shoehorn the OSGi logic into Redtamarin core as native or as a builtin, that not gonna happen.

Manage your module in ActionScript with OSGi if you want, but you can not force that on all other users of Redtamarin.

clearer?

I’ll tell you another truth micro-services came to existence with OSGi and how OSGi is doing micro-services it is not with HTTP or any other external means of communication but rather it all happens inside of the JVM. The term micro-services was invented by the author of the OSGi Standard. What you call micro-services with HTTP in the web world is not micro-service.

If you want to educate yourself about what is what here the creator of OSGi answer on stackoverflow: https://stackoverflow.com/questions/49443206/difference-between-osgi-and-microservices/49445282

Web “”"""“micro-service”""""" needs to communicate with external means and it is not micro-services. OSGi it is at the runtime level that all happens. That’s the difference.

I don’t want to force anything on you I just want you to be not biased.

Now they had to change their original concept name micro-services to nano-services because of the bastard from the web.

it’s all open source, feel free to make a fork and mix all you want OSGi with AVM2.

I will not do that with Redtamarin.

Maybe, and I don’t think I changed those with Redtamarin.

Now, I also don’t feel Redtamarin need to be OSGi compliant because someone said so.


Let be clear, Redtamarin just add API on top of the AVM2, we do not even try to change the runtime itself, except when we have no other choice to hook particular things, like intercepting exit event with atexit() or being able to catch signals like SIGHUP SIGTERM, etc.

Now whether we agree or disagree on OSGi itself, it does not really matters
you can implement it in ActionScript and so use it with Redtamarin too if you want
so where is the problem?

is there something in Redtamarin that prevent you to do OSGi?

No actually you didn’t really understood what was my suggestion. It was not to do OSGi with redtamarin but to put at the lowest layer OSGi so that the AVM2 can become dynamic to receive and leave independant functionalities that could be used by the higher levels like redtamarin. To be able to swap code at runtime and bring new functionalities offers endless possibilities of extensions. I didn’t dig into tamarin so maybe there is a place where I don’t get what you say about your architecture choice and that’s totally normal.

I just saw a huge foreseeable direction where the AVM2 could go.

That’s the original post : https://blog.osgi.org/2010/03/services.html

I understood that as doing it at the source level in C++ with CppMicroservice
and I’m opposed to that for many good reasons

yeah this swap code at runtime, with AS3 if you want, but with C++ that’s a whole different level of complicated and I might add unnecessary complicated.

I do not think that using OSGi/CppMicroservice will magically make easy to add 3rd party C++ code into Redtamarin.

Do that for AS3 if you want, but C++ is not gonna be that easy.

Also, in term of architecture it has not be planed like that
we added a C API for AS3 developer to add the low-level functionality they want
maybe later we will add something like CrossBridge compatibility to be able to reuse 3rd party C libs, but so far now the logic is to write yourself the code you need with the C API available in AS3.

But that is the design, we will provide classes like Socket, ServerSocket etc.
but if we were not providing those or you need something specific,
you can use those low-level C API to implement exactly what you need/want
in fact, there AS3 is like C++, and the design is like that so dev can easily compile AS3
and not deal with compiling C or C++.

This is really easy and your belief is wrong and that’s why OSGi exists to make that aspect effortless. It is not complicated at all it only depends on your knowledgeability and level of creativity. Architecture and coding should be easy and not complicated. If you find things complicated then the limitation comes from you. I think that most developers are coding too logically without an ounce of creativity outside of the box. OSGi follows the principles of nature concerning modularity, in nature everything is in Harmony when you use OSGi your whole code become a natural pattern. I would say that not every developer is open to connect with the spiritual aspect of programming but that’s ok. CppMicroservice is almost like magic until you try it. Having dynamic code at the AS3 level is a great indicator that the people who built the C++ code that handle that dynamism are pretty genious and creative. If that exist in the C++ side but it is statically compiled once for the runtime, I would say making that part also dynamic is a great addition. You see my expertise in how to create dynamically evolving systems… you are talking most of the time of static code. I’m just in another realm where everything you see problematic is already taken care of.

I’m talking about implementing CppMicroservice to render the AVM2 modular so that new C++ code (bundles) coming into the framework, adds new class that can be right away used from the AS3 part. How do you make an VM dynamic at the C++ side is only impossible for you but for me it is almost there. The genius has to do the missing pipping.

Look whether it is easy or not does not really matter
I’m not improvising on a whim what to add/modify/remove on a daily basis

what I know is Redtamarin/Avmplus as a C++ project is something hard
if you think it is easy you might underestimate the project itself

ok great, you caught me
I’m not knowledgeable and I have no creativity
and sure the limitations come from me because I don’t want to do what you are suggesting

Now, because it is so easy, and so effortless and so not complicated
and only my shortcomings are blocking you to get OSGi mixed into the Redtamarin C++ sources

hey look it is all open source, just grab the C++ sources, add OSGi, compile and done
right ?

please do that and come back telling me how wrong I was to not have done it earlier
I will wait

yeah sure, just let me know when you have implemented/mixed all that OSGi stuff into Redtamarin or Avmplus, what is your time estimate? 1 week ? 1 month ?

it is almost there right? so should not take too long right?

you do realise you talk a lot in theory but please if you want to continue all this talk, come back with some stuff compiled that are actually working, more compiling less talking.

Until then, I will continue working on Redtamarin the way it has been designed and so without all that OSGi bullshit.

When should I expect your compiled version of “improved redtamarin with OSGi” ?

2 Likes

When I’m done with what I am doing right now I will dive into how to hook CppMicroservice into the core from redtamarin. I will probably need your guidance to where to start to look at and where I need to pay special attention. I really don’t know much how redtamarin is working but I’ll dive into it.

Again the only bullshit which exists is the one in your head. Remember there is no spoon(bullshit) NEO.

hey no problem that’s something easy and effortless so you should cruise through it without too much trouble