I am forwarding an extract of a discussion we had internally but we would like to open it so everyone can express their feedback and opinions. ---------- Forwarded Message ---------- Date: Wednesday 07 November 2007 From: Duncan Mac-Vicar Prett <dmacvicar@suse.de> To: Klaus Kaempf <kkaempf@suse.de> In YaST we have a problem. We don't have a multi-language/API foundation strategy. Which languages we support, and which we write our infrastructure in. Right now we have the YCP layer as a hub between languages, which gives us a nice component framework where we could write clients in any language and modules in any language. If we stay with this strategy, we need to fix two big issues: a) market YCP as a component model, and not as a language b) provide a easy way to glue natve code to ycp components. Last time I looked how pkg-bindings is implemented, it is _sick_ and you have to deal with symbol tables etc. The most sane way is generating perl bindings and then using it as a component. Why not auto-generating direct ycp glue? Once you follow the dependencies outside of YaST core, YaST is not that "light". The other possible strategy is to choose a platform, say Python, Ruby whatever, and that mean rewriting, which is what we will not do. The other possible strategy is to migrate our existing code to some standard infrastructure. The most known are jvm and CLR. LLVM probably won't qualify because it is too low level and Parrot seems to be still vaporware in respect of language support. If we are able to migrate (recompile) our code to one, it means we gain all target language compilers and that we can make use of the code writen in any of those plus all the code which is already written out there. Also we would gain nice IDEs, debuggers, profilers, standard tools and others. Only when I write Java in Eclipse I realize how much C++ tools suck. (no CDT is not good enough). I don't know more strategies. If anyone knows another one, speak up!. I don't know also which one is the best. I want all lines of research open, and if it possible, try them. Duncan ------------------------------------------------------- Date: Wednesday 07 November 2007 From: Klaus Kaempf <kkaempf@suse.de> To: Duncan Mac-Vicar Prett <dmacvicar@suse.de> I'd recommend to take this thread on yast-devel ! * Duncan Mac-Vicar Prett <dmacvicar@suse.de> [Nov 07. 2007 13:03]:

In YaST we have a problem. We don't have a multi-language/API foundation strategy.

Which languages we support, and which we write our infrastructure in. Right now we have the YCP layer as a hub between languages, which gives us a nice component framework where we could write clients in any language and modules in any language.

If we stay with this strategy, we need to fix two big issues: a) market YCP as a component model, and not as a language

That was the original intention: YCP as a low-level, abstract, non-binary protocol / model to glue different components, namely the backend (scr) and the frontend (UI) together. However, nowadays there are standardized, open-source means available for both the backend (hal/dbus for local, cim for remote) and frontend (html/css being the most prominent) available. We'd rather deprecate ycp going forward and look for migration strategies away from it.

b) provide a easy way to glue natve code to ycp components. Last time I looked how pkg-bindings is implemented, it is _sick_ and you have to deal with symbol tables etc. The most sane way is generating perl bindings and then using it as a component. Why not auto-generating direct ycp glue?

Sure, why not ? I think the ycp layer still gives us a lot of unexplored capabilities and I hope the 'language independence' workgroup will look into them.

Once you follow the dependencies outside of YaST core, YaST is not that "light".

Right. And following customers requests, we'd rather fix this too.

The other possible strategy is to choose a platform, say Python, Ruby whatever, and that mean rewriting, which is what we will not do.

Rewrite from scratch ? Certainly not. Migrating from YCP to another language platform ? Why not ?

The other possible strategy is to migrate our existing code to some standard infrastructure. The most known are jvm and CLR. LLVM probably won't qualify because it is too low level and Parrot seems to be still vaporware in

respect

of language support. If we are able to migrate (recompile) our code to one, it means we gain all target language compilers and that we can make use of the code writen in any of those plus all the code which is already written out there.

This includes a high risk of 'language chaos' with every component written in a different language, all glued together by a VM. A scenario we better stay away from. The current situation (bad support for popular/useful languages) is as bad as having no limits at all. We have to define requirements and limits and, based on them, make a platform/strategy decision.

Also we would gain nice IDEs, debuggers, profilers, standard tools and others. Only when I write Java in Eclipse I realize how much C++ tools suck. (no CDT is not good enough).

Availability of tools is a very important decision factor.

I don't know more strategies. If anyone knows another one, speak up!. I

don't

know also which one is the best. I want all lines of research open, and if it possible, try them.

Research looks at technical possibilities, then market/budget requirements will limit them to a reasonable number. Klaus ------------------------------------------------------- ------------------------------------------------------- ---------- Forwarded Message ---------- Date: Wednesday 07 November 2007 From: Stanislav Visnovsky <visnov@suse.cz> Dňa Wednesday 07 November 2007 13:02:54 Duncan Mac-Vicar Prett ste napísal:

In YaST we have a problem. We don't have a multi-language/API foundation strategy.

Which languages we support, and which we write our infrastructure in. Right now we have the YCP layer as a hub between languages, which gives us a nice component framework where we could write clients in any language and modules in any language.

If we stay with this strategy, we need to fix two big issues: a) market YCP as a component model, and not as a language b) provide a easy way to glue natve code to ycp components. Last time I looked how pkg-bindings is implemented, it is _sick_ and you have to deal with symbol tables etc. The most sane way is generating perl bindings and then using it as a component. Why not auto-generating direct ycp glue? Once you follow the dependencies outside of YaST core, YaST is not that "light".

The other possible strategy is to choose a platform, say Python, Ruby whatever, and that mean rewriting, which is what we will not do.

In the end, we will have to decide the preferred language, just to be able to maintain the stuff, having backup maintainers etc. From that point, I don't see many arguments why not move slowly toward that, on case-by-case basis.

The other possible strategy is to migrate our existing code to some standard infrastructure. The most known are jvm and CLR. LLVM probably won't qualify because it is too low level and Parrot seems to be still vaporware in respect of language support. If we are able to migrate (recompile) our code to one, it means we gain all target language compilers and that we can make use of the code writen in any of those plus all the code which is already written out there. Also we would gain nice IDEs, debuggers, profilers, standard tools and others. Only when I write Java in Eclipse I realize how much C++ tools suck. (no CDT is not good enough).

We would also get all the politics and myths attached to those technologies. Unfortuantelly, they will only add, not replace ones we already have attached to YaST ;-)

I don't know more strategies. If anyone knows another one, speak up!. I don't know also which one is the best. I want all lines of research open, and if it possible, try them.

I believe the overall impression for those technologies are going against us, and you cannot do much about it. Java will be the slow virtual machine and great development platform for next 10 years. Mono will be patent-ridden and Microsoft for the next 10 years. I'm afraid we cannot afford at this point to get into that game as it will just worsen the YaST image. I'd hope to be proven wrong! Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org