Hi, I am not against C++, just because of the language. I am just questioning - what are the benefits. Is it worth the effort, put into it. I guess a relevant benchmark/metric data would make such decision easier.
I am mostly comparing Celix to Karaf, but I would have to compare it against Felix, I guess. As far as I know, even Karaf/Felix was once one project, that broke into separate projects, each with a dedicated focus/goal. For Karaf I know few big companies that use Karaf in their product lineup, and as such I know what are the design goals, what are the focus areas. With Celix I do not have such a clear picture. With that said. What I meant with additional features was ( and I guess some are not "core" Celix features ) things like: support for group package deployment, like Feature in Karaf - list of bundles with dependencies and dedicated repository for dependencies. For Celix it would be really neat if apt/yum repositories could be re-used ( I guess there are other, newer package managers out there, but most of my work is around RHEL 7.5/8 and Ubuntu Linux ). Again, as I do not know the goal/focus for Celix, I do not know if appropriate or not, but things like Cellar would be awesome to have - where one could easily distribute package deployment among nodes. Out of the box support for REST queries for deployed bundles and "simple" deployment/management API. Support for bundles in other language - for example, write Java class / bundle with activator ( support for Java-based OSGi spec ) and wire into Celix - use other/exiting services. In my design I would implement such solution in connection with ASN.1 description of the interfaces ( or some other "low level" data protocol ) - something like ( or exactly like ) FastWebservices (Defined in ITU-T X.892 | ISO/IEC 24824-2 ). I guess, this would not be really performance best job, as no one can avoid JNI penalty, but if someone needs it - it can benefit from it. One other thing is to make it compile/run on as many hardware/OS platforms as possible and promote the solution to projects like HEMS, SmartGrid, energy trading platforms, etc ( this are the fields I know, so I guess other related could also benefit ). Nowadays all sort of such solutions are written in PHP, Java, C#, JS or what ever new language someone thinks out this days. Celix is like core of the "module platform", but I guess core is OK, but project needs ecosystem around it, that builds on top of the benefits/features provided. My goal for sure is to "grow" Celix in a path like "big boys", for example as Karaf. I know I am "mixing projects" a bit, but pure OSGi implementation is not usable on its own -- it needs usecases and provide solid solutions/alternatives. In my early PoC projects, for same functionality I can outperform Karaf-based solution for around 100x -- in the same time Celix/C can serve 100x more clients or 100x more packages, but to be able to compete all the surrounding ecosystem needs to exist ( integrated deployment, integrated clustering, integrated etc ). As it is now, it is not cost effective to go in that direction, no one will approve such a route. I am sure someone needed Celix and at that time, there must be some "goal roadmap", what is the purpose to build Celix. I guess it was not for fun to implement OSGi in C. No one can have so much time, to have fun, I guess C is one of the last languages someone picks to make things modular and dynamically deployable in runtime ( I was referring to application landscape, not kernel modules etc). Other thing is, that I did not have Celix application running for non-stop over long period of time in production. So I can not really comment on stability, but for what I was testing it was working quite stable and did not run into any crash - from Celix, it crashed from inside one of my bundles. I did not even dive deep into Celix, I did at the begging, but not ever since. I guess over time, every project has heavy weights that could be cut out. But this is thread related to C++, so I went out of the topic focus. So my "final" comment on the subject is: if C++ based implementation has benefits and has similar or better characteristics compared to existing code base I am all for it, but to me C is really fun language, that if treated with love in can do whatever new-age language can do. And not to forget: existing work is really nicely put together and congrats to all the authors. Kind Regards, Miroslav V V čet., 10. jan. 2019 ob 21:54 je oseba Pepijn Noltes < [email protected]> napisala: > On Wed, Jan 9, 2019 at 3:39 PM Gabriele Ricciardi > <[email protected]> wrote: > > > > Hi all, > > > > as for many things, in my opinion there are many pros and cons in moving > to > > a C++ implementation of the framework. > > > > I discussed the subject with Pepijn already few times, and he has many > > points: C++ is a popular language, and offering support for it will > surely > > give more visibility to the project and also give more opportunities to > the > > end developers for choosing Celix as base framework for their > applications. > > I can agree on some technical arguments like type safety and smaller/more > > compact code base that may increase the maintainability. > > I also understand that using some of the modern C++ construct can make > life > > easier when it's about implementing core parts of the framework. > > Moreover, I also think that introducing C++ support may open new horizons > > for "pure" C programmers (like me). > > > > I'm not really concerned about the possible stability issues we may > > encounter, Celix got pretty stable in the last few years and I don't see > a > > reason why a different implementation can't reach the actual level of > > stability (or even better). > > > > What concerns me a bit more is the possibility of eventually dropping the > > support for C: of course the current implementation should (or better, > has > > to) improve, but honestly I think that arguments like RAII and error > > handling are not sufficient to justify such a swift direction change. > > > > As Miroslav pointed out, C is a bit more verbose but is also very stable > > throughout years, the code is (in my opinion) more readable and, if well > > written, it is portable and not really error-prone: basically, I agree > with > > C being a "holy grail" and as developer I would always like to have the > > opportunity to play that card. > > > > For those reasons I think that moving and concentrating only on C++ and > > just provide a "(mostly) backwards compatibility C API" (for eventually > > phasing it out) would be a real pity. > > > > In my opinion, support for C and C++ should get the same attention and > try > > to provide (as far as allowed by the specific language) the same > > functionalities: in the end, I don't see a problem in keeping up with two > > implementations, even if one will be a bit more verbose or slightly > harder > > to code (of course, benefits should always outweigh or at least balance > the > > efforts, so if a new feature is easy to implement in C++ and nearly > > impossible to implement in C... well, it will be unsupported for C). > > > > On the contrary, I do see the benefits of keeping up with two > > implementations: we can really provide a flexible framework that gives > the > > end developer the possibility to choose what he thinks it' better for him > > and his application. Of course it will require a bit more effort on our > > side, but I see it as a good opportunity to bring Celix to the next > level. > > I have not though about maintaining a C and C++ version and my first > reaction is that we should not do this, but > to be honest I have to think about this. > > > > > > > > Kind regards, > > > > Gabriele > > > > Il giorno mer 9 gen 2019 alle ore 09:29 Miroslav Beranič < > > [email protected]> ha scritto: > > > > > Hi all, > > > > > > I've started working with Celix back at 2015. At that time, I as "all > about > > > C++" and thought about C as "C++ predecessor that will fall out", so > C++ > > > was obvious was forward. With use of Celix, I've started to see > solutions > > > implemented in C that at that time I thought "only possible in C++". > With > > > time, I've dropped C++ all-together as to my opinion, C++ standard is > > > moving to fast to radical. For example, Google C++ Style Guide advice > on > > > the C++ is: > > > > > > " Currently, code should target C++11, i.e., should not use C++14 or > C++17 > > > features. The C++ version targeted by this guide will advance > > > (aggressively) over time. > > > Code should avoid features that have been removed from the latest > language > > > version (currently C++17), as well as the rare cases where code has a > > > different meaning in that latest version. Use of some C++ features is > > > restricted or disallowed. Do not use non-standard extensions." > > > > > > Over time I've started to appreciate the simplicity of C ( this does > not > > > mean it is less capable ). With C++ there is so many hidden things > > > generated, it starts to feel like Java. One note here: my day-to-day > job is > > > around Apache Karaf, Camel, JMS, ... enterprise integration; but more > and > > > more I am thinking about porting ( step by step ) from existing bloated > > > environments where all I want is move data from one end to another to > > > simple & fast - like Celix. But here, yes - there is a lot of missing > > > components that Java based "OSGi implementation" counterpart already > has. > > > And it would make ( financially ) no real benefit -- no one will > approve > > > such a project to me. > > > > > > In my "night time" job I use Celix since day one of using Celix. All I > want > > > from Celix is that it is simple and runs super fast ( and for sure > stable > > > ). > > > @Pepijn, you might do not remember that I wrote about C++ back in > 2015. You > > > wrote back: > > > "I think support bundles written in other (native) language is quite > > > feasible. I even started prototyping with some Swift code (which is > > > promised to become open source) . The beauty about C is that it is the > > > common dominator for native languages and therefore ideal as core > framework > > > language. > > > The biggest challenges would be how and if those bundles can share > services > > > written in different language. So cpp pure abstract class as service > used > > > in a C bundle ?? > > > Note that this is my opinion and not _the_ Celix policy, everything is > > > discussable." > > > > > > At that time I really started to thing about C as common nominator. > Now I > > > have same code base ( with some obvious differences ) running on > Arduino, > > > Android, RaspberryPI ( Yocto project ) and WebAssembly ( all about > moving > > > data from one end to another using ASN.1 ). To me C is holy grail. It > does > > > have more verbose syntax and it does not all the compile-time checking > as > > > C++ does ( a lot has void* ), but it produces a lot smaller/portable > code. > > > I agree also, this is possible also because I do not know all the > latest > > > bells and whistles from C++. To me C++ is like moving target. It is > modern > > > now, in 5 years time we are talking about "old" C++. With C, code base > from > > > 15 years ago works and documentation is valid. > > > > > > At the and I agree someone will start to implement C++ "version of > Celix" > > > as this is reality. I also agree this should be Celix community, not > some > > > outside community. I would also argue that there should be only C and > only > > > C++ implementations as from my experiences, mixing C and C++ is > useless. It > > > does not have C way of work, it does not have C++ way of work. And C++ > is > > > not "just" C with classes. I do agree C++ has benefits, but we all > should > > > know what those benefits are. Also what is the goal of Celix, what is > > > roadmap. Is this even an option? > > Well said and I agree with this - especially, because you also quoting > me... ;). > Specifically the fast movement of C++ language - although that also > has it benefits - is indeed a real concern. > This combined with the idea that C++ is a "expert friendly" language, > creates a risk that the code can become "old" quickly and as result > inverse the maintainability. > > I also still think that C is the more clean and elegant language and > that it is also the common nominator to expand to other languages. > The thing is, that the common nominator part can be done by providing > a C API from a C++ implementation and maybe I see this incorrect, but > I do think the combination (with effort) of C/C++ is feasible. > > When I started working on the C++ implementation I was quite surprised > at the progress I was able to make (and for that reason, I probably > took this experiment to far before discussing this) and > combining this with ability to create a more concise user API and the > popularity of C++ is the reason I think we should really consider > this. > > To be clear If the general consensus it that we should keep the focus > on C I have no problem with. I enjoy writing code in C and I also > agree with Gabriele that - if done well - C delivers very readable > code (it just requires lots of lines of codes .. ). > My point is that the goal of Celix is what we as community make of it > and to keep Celix relevant I have no problem changing this when needed > (e.g. more or less strict on OSGi or implemented in C or C++). > > > > > > > > What I am missing from Celix is added functionality. At the end do not > > > really care C or C++, as long as the metrics are what is expected. > > > > > > Regarding my metrics data questions, my wife was recently awarded PhD > > > regarding measuring metrics in software, so I am all about metrics this > > > days. Did not plan to be "rude" or anything. Main point was - is it > > > possible to measure benefits of going forward with C++ or not. Is this > data > > > showing better results or not? Would new/better/updated version of C > > > implementation yell better results? If we can put scale and values on > that > > > scale, decision would be easier. To me it is all about code size it > > > produces and speed it executes ( with stability). > > No worries. I did not think it was rude and I am actually happy with > the feedback/comments. > And metrics would indeed be welcome, but is just something we have not > put effort in. > > > > > > > With languages I was thinking about Lua ( not really programming > language, > > > but hey ... ), Rust, Dart, Java. I guess most of this can be solved > with > > > bindings. > > Ok thanks, I was just curious. I know there has been no real progress > on other languages - well except C++ ;) -, but this is something I > still really would like. > There is btw hopefully a window on my "day job" to pursue support for > Python, > > > > > > > To close this one: Go with C or C++, but do not mix. If core needs to > be > > > updated it would be nice if it could be done in C ( in existing code > base > > > ). If C++ is taken, use it with all the features it has and not use it > as > > > C. In either way Celix needs more added functionalities ( with clear > goals > > > and roadmap ). > > Good point. I still think that the current core framework in not good > enough yet and as result are still focusing on refactoring the > implementation and API of the Celix framework. > But are there any specific features/functionalities you think Celix is > missing? > > > > > > > Kind Regards, > > > Miroslav > > > > > > > > > > > > > > > > > > > > > > > > V V tor., 8. jan. 2019 ob 21:24 je oseba Pepijn Noltes < > > > [email protected]> napisala: > > > > > > > Hi, > > > > > > > > On Tue, Jan 8, 2019 at 7:13 PM Gerrit Binnenmars > > > > <[email protected]> wrote: > > > > > > > > > > Hello Pepijn, > > > > > > > > > > I am a bit concerned by this move. Introducing C++ in the framework > > > makes > > > > > Celix no longer a dynamic service framework for C. > > > > > I understood the support for C++ in the API, so C++ bundles were > > > > supported, > > > > > but this is something different. > > > > > > > > Note that even if the framework is done is C++, we can still deliver > a > > > > C API - for the framework and for the services provided by the > > > > bundles. > > > > It does add a mandatory requirement to a C++(11) compiler and > > > > dependency to libstdc++. > > > > > > > > My concern here is that moving to C++ could (eventually) lead to some > > > > bundles only provided/consuming a C++ API and shut out C support. > > > > > > > > > A lot of effort is put in the code quality and stability of the > > > > framework, > > > > > does this work need to be done once more? > > > > > > > > I understand your concern, and yes of course recreating the framework > > > > will lead to some stability issues. > > > > I started experimenting with a C++ framework for two reasons; 1) I > > > > wanted to tryout what features/concepts of C++ we should include in a > > > > C++ API to make it more accessible for C++ users and 2) IMO the > > > > current implement/design of the Celix framework is flawed and as > > > > result we still run into stability issues. Those two issues combined > > > > are there reason there is now an experimental C++ branch. > > > > > > > > Wether we decide to move to C++ or not, I still think we need > recreate > > > > the celix framework. > > > > What if forgot the mention in the previous mail is that in the C++ > > > > registry all registration/unregistration and the starting/stopping of > > > > trackers are handled in registry and with use of ref counting & async > > > > calls (future) to prevent deadlocks in the framework; this is > somewhat > > > > complex, but manageable. For the current celix implementation this > > > > partly done in the framework object, the service registry object and > > > > the service tracker object and this combined with (no ref count) > > > > handling of services references & service registrations and a lot of > > > > entanglement between those objects currently still leads to race > > > > condition / dead lock issues. > > > > This approach can also be done in C, but requires simple more lines > of > > > > code ... > > > > > > > > With the updated C API I also started cutting out some > > > > concepts/complexity we IMO do not need (service references, bundle > > > > archive, bundle revision, module, service listeners, service listener > > > > hooks, framework listener), with the idea to eventually drop those > > > > concepts. These concepts are already dropped in the current C++ > > > > framework implementation. > > > > > > > > So moving forward with C or C++ we should IMO (eventually) go for a > > > > 3.0 release with a more lean API, implementation and support for > > > > bundles as linkable shared objects. > > > > And this will lead to some stability issues, but for sure become a > > > > more stable and maintainable framework in the end. > > > > > > > > > > > > > > My conclusion: I would prefer to keep the framework as is and > > > concentrate > > > > > on adding functionality. > > > > > A C++ framework implementation does not bring enough to Celix. > > > > > > > > Functionally I agree, but it does arguable result in less lines of > > > > code framework .. i.e. a better maintainability & productivity. > > > > > > > > > If you really want to continue this should not go into Celix but > in a > > > new > > > > > Apache project. > > > > > > > > I do not agree. Yes it would introduce back incompatibility changes, > > > > but that does not make it a different project. > > > > > > > > > > > > > > I am quite curious what the rest of the community thinks. > > > > > > > > Indeed... > > > > > > > > > > > > > > Gerrit > > > > > > > > > > > > > > > > > > > > On Mon, Jan 7, 2019 at 11:19 PM Miroslav Beranič < > > > > > [email protected]> wrote: > > > > > > > > > > > Hi Pepijn, > > > > > > > > > > > > is there any metric data regarding performance, code size etc - > > > > compared C > > > > > > and "new" C++? > > > > > > > > Code size I do not know, but is something we can measure. > > > > > > > > For performance I assume you mean the overhead of calling services? > > > > I have no metric for that .. although that would be nice. > > > > > > > > In my reasoning as long as you can still provide/consume pointers to > C > > > > service structs (as with the current Celix framework) for C usage, > > > > there is no performance difference. > > > > And the goal of the C++ framework should be to still a) support a C > > > > API and b) support C service struct. So there should be no change. > > > > > > > > For C++ usage there will be the overhead of dereferencing the > > > > std::shared_ptr and overhead of accessing a std::function / pure > > > > abstract C++ interface (i.e. virtual method). > > > > > > > > > > > > > > > > > > > > Is there any plan to support other languages ( using language > > > bindings > > > > ) ? > > > > > > > > A C API, conform the current updated (celix_* headers) C API, should > > > > IMO be added 'out of the box'. Any other languages you where thinking > > > > about? > > > > > > > > > > > > > > > > From my side, I would really like to see C version, but I guess > C++ > > > is > > > > > > "must have". > > > > > > > > > > > > Kind Regards, > > > > > > Miroslav > > > > > > > > > > > > > > > > > > V V pon., 7. jan. 2019 ob 22:25 je oseba Pepijn Noltes < > > > > > > [email protected]> napisala: > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > The last weeks I put some effort in exploring the benefits and > > > > > > > downsides of changing the primary language of Celix from C to > C++ > > > in > > > > > > > an experimental branch. > > > > > > > > > > > > > > As you probably already know Celix start around 2010 with the > focus > > > > on > > > > > > > a OSGi implementation in C; following the Java OSGi spec very > > > > > > > strictly. And IMO that was correct choice at that time and > with our > > > > > > > given experience. > > > > > > > My current vision is that we should follow the concepts of > OSGi and > > > > > > > where possible the nomenclature, but focus on delivering a (as > much > > > > as > > > > > > > possible) easy to use dynamic services framework for C/C++. > > > > > > > > > > > > > > IMO this also means that we should think about moving to C++. > > > > Because: > > > > > > > a) With the concepts of C++11 we can create a much easier to > use > > > and > > > > > > > hopefully also easier to develop/maintain framework. > > > > > > > b) More type safe > > > > > > > c) RAII; which really helps a lot in dealing with volatile > services > > > > > > > and trying to keep track of which services are still in use. > > > > > > > b) C++ is simply more relevant and popular, which should help > in > > > > > > > getting more traction for Celix. > > > > > > > > > > > > > > To get the discussion rolling and for me to get a feeling what > the > > > > > > > effect of moving to C++ would mean, I created C++ experimental > (but > > > > > > > functionally quite complete) Celix C++ framework [1]. > > > > > > > And I would like some feedback/discussion if this is an > improvement > > > > > > > for Celix or any remarks on the Celix C++ framework > implementation. > > > > > > > > > > > > > > There are a few interesting changes in the approach/design of > the > > > C++ > > > > > > > framework: > > > > > > > 1) There is a separate (static) Registry library [2], which > > > delivers > > > > > > > the functionality to register/use/track (and TODO listener > hooks) > > > > > > > services. This library, by design, can be used without the > rest of > > > > the > > > > > > > framework. I designed the Registry library separate to keep it > > > clean > > > > > > > of bundles lifecycle stuff. > > > > > > > - ServiceRegistration/ServiceRegistry uses RAII to make it > > > easier > > > > > > > in use, specifically for cleanup. > > > > > > > - The registry also support registering std::function as > > > services, > > > > > > > this seems logical for C++. > > > > > > > - The service template argument is used to deduce the > service > > > > name. > > > > > > > - The concept of services versions is dropped. I do think > > > versions > > > > > > > on API is important, but more in a distributed environment. In > my > > > > > > > experience for Celix everything should be build against the > same > > > > > > > service API's. Playing around with backwards compatibility on > > > binary > > > > > > > level with C++ is just reasonable. > > > > > > > 2) The framework library [3]. Here the focus in on the > > > BundleContext > > > > > > > api so that almost everything can be done through the bundle > > > context > > > > > > > api. > > > > > > > - It is now also possible to register "static" bundles. These > > > > > > > bundles are installed on every created Framework object. This > make > > > it > > > > > > > possible to register bundles with use a > > > __attribute__((constructor)) > > > > > > > decorated function. With support for "static" bundles, bundles > can > > > be > > > > > > > created as shared objects, which "just work" if you link > against > > > > them. > > > > > > > See the C++ Shell example [4]. IMO this is a much .. much more > > > > natural > > > > > > > way to handle bundles in a C/C++ environment. > > > > > > > - Support for zip bundles and dynamically loaded shared > object - > > > > with > > > > > > > use a the bundle create, start,stop ..etc symbols is still TODO > > > > > > > - BundleActivator now work on the constructor/destructor, i.e. > > > also > > > > > > > following a RAII approach. > > > > > > > - There is no concept of a ServiceReference (same as in the > > > updated > > > > C > > > > > > > api). > > > > > > > 3) Resources can be linked against a shared object and in that > way > > > > > > > OSGi extender pattern concept can be used without using zip > files > > > as > > > > > > > bundles. See the C++ Shell implementation as an example (this > > > bundles > > > > > > > has a version.properties resource) [5]. > > > > > > > 4) For now glog is used as logging framework. > > > > > > > 5) libzip is used to handle the zip files. Note that resources > > > linked > > > > > > > against the shared object bundles are packed as a zip file. > > > > > > > 6) googletest is used for testing. > > > > > > > - It is also easier to test bundles, because the test > executable > > > > > > > "just" has to link against the bundle shared objects to make > them > > > > > > > available. See the tests of the C++ Shell bundle [5] > > > > > > > 7) For now there is no way to export/import (versioned) shared > > > > objects > > > > > > > from other bundles. I personally do no think this is really > needed > > > (I > > > > > > > never use it myself). I also think that this should be solved > by > > > the > > > > > > > language itself (i.e. C++ Modules). > > > > > > > 8) As far as I can see it is possible to create a (mostly) > > > backwards > > > > > > > compatibility C API from the C++ framework. As long as we only > > > > support > > > > > > > the updated C API, i.e. the the celix_* headers. > > > > > > > > > > > > > > The C++ framework API has no documentation yet, please be > aware. I > > > do > > > > > > > think that it should be clear enough for experience users and > the > > > > > > > developers, but this is still a TODO. > > > > > > > Currently for C++ there is a Registry [2] library, a Framework > > > > library > > > > > > > [3], a C++ Shell bundle [5], a C++ Shell TUI bundle [6] and a > > > single > > > > > > > example executable to run everything [4]. > > > > > > > I also took some effort to ensure that the code coverage > result are > > > > > > > generated and somewhat respectable. > > > > > > > > > > > > > > My experience thus far is mostly positive. Fewer lines of code > are > > > > > > > needed (duh), but also (mainly because of RAII) less if else > > > branches > > > > > > > are needed / error handling is needed. > > > > > > > I do have some trouble arrange the code, because some part > need to > > > be > > > > > > > in the header (template) or in Impl classes to ensure a more > clean > > > > > > > user API and the rest is in the sources files. > > > > > > > > > > > > > > Please feel free to let me know what you think. Note that this > is > > > > > > > still experimental and we will discuss how to move forward > later. > > > > > > > > > > > > > > [1] feature/cxx branch (for the 807b88 .. commit): > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f > > > > > > > [2] registry dir: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/libs/registry > > > > > > > [3] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/libs/framework_cxx > > > > > > > [4] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/examples/celix-examples/cxx_shell_example > > > > > > > [5] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/bundles/shell/cxx_shell > > > > > > > [6] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/celix/tree/807b88b5bb166e253dc1c517326d2865bc60584f/bundles/shell/cxx_shell_tui > > > > > > > > > > > > > > > > > > > > > Greetings, > > > > > > > Pepijn > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Miroslav Beranič > > > > > > MIBESIS > > > > > > +386(0)40/814-843 > > > > > > [email protected] > > > > > > https://www.mibesis.si > > > > > > > > > > > > > > > > > > > -- > > > Miroslav Beranič > > > MIBESIS > > > +386(0)40/814-843 > > > [email protected] > > > https://www.mibesis.si > > > > -- Miroslav Beranič MIBESIS +386(0)40/814-843 [email protected] https://www.mibesis.si
