Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
[yast-devel] Fwd: discussion about YaST infrastructure and foundation
  • From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
  • Date: Thu, 8 Nov 2007 10:04:46 +0100
  • Message-id: <200711081004.46471.dmacvicar@xxxxxxx>

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@xxxxxxx>
To: Klaus Kaempf <kkaempf@xxxxxxx>


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@xxxxxxx>
To: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>


I'd recommend to take this thread on yast-devel !


* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [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@xxxxxxx>

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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups