Hi,
While reviewing the different extensions for the windows build, I
found that many are unmaintained without any commit since year(s).
Other are already removed from HEAD and some may be continued to
live in core but it would require some love.
-
Extension being deleted (not removed, a "cvs rm" will be done)
mhash, no impact as we provide a compatibility layer via ext/hash
(Thanks to Scott) -
Extension looking for love (if noone raises the hand, they will end
in PECL too)
-
ncurses
I can help here for the windows port and pdcurses support on unix and
windows. Hartmurt agreed for the move it to pecl for 5.3. -
smnp
nice ext, any ISP out there willing to help? I can help for the windows support
Can be moved PECL
- interbase
- fpdf
- fbsql
- sybase and sybase_ct
Please let me know if you can either help to maintain an extension or
if you see any issue with one of these moves.
Cheers,
Pierre
Pierre Joye wrote:
- smnp
nice ext, any ISP out there willing to help? I can help for the windows support
Hmm, we use this. Is it broken for 5.3 or something? What do we need
to do to keep this alive?
--
Brian Moon
Senior Developer/Engineer
When you care enough to spend the very least.
http://dealnews.com/
Hi Brian,
Pierre Joye wrote:
- smnp
nice ext, any ISP out there willing to help? I can help for the windows
supportHmm, we use this. Is it broken for 5.3 or something? What do we need to do
to keep this alive?
It is not maintained, no one develops or maintains it. I successfully
build it on windows using the latest snmp libs, however it would be
much better if there was actually a maintainer. I sadly can't take
care of it alone and it does not make sense to keep a non maintained
extension in php. As snmp is not the most popular extension, I do
understand that it is really helpful to have good snmp support with
php. That's why I made a call for volunteers instead of putting it in
the "to be moved out" category.
Do you feel like you can give it some love?
Cheers,
Pierre
Hi,
Extension being deleted (not removed, a "cvs rm" will be done)
mhash, no impact as we provide a compatibility layer via ext/hash
(Thanks to Scott)
We should keep this somewhere in Siberia like we did with other
extensions we removed. (PHP 4 XML stuff for instance)
- Extension looking for love (if noone raises the hand, they will end
in PECL too)
- ncurses
I can help here for the windows port and pdcurses support on unix and
windows. Hartmurt agreed for the move it to pecl for 5.3.
hm, I thought this was already done, go for it.
- smnp
nice ext, any ISP out there willing to help? I can help for the windows support
Last time I checked it worked nicely and I know other user which have no
problems either, so I guess there's not much maintenance needed. The
only thing I see is implementing new parameter parsing API.
So I don't see a reason to move it to PECL.
Can be moved PECL
- interbase
- fpdf
- fbsql
- sybase and sybase_ct
Moving fpdf shouldn't be a problem, for the others I can't really judge,
I don't know a user of these, but that's me.
johannes
hi,
Extension being deleted (not removed, a "cvs rm" will be done)
mhash, no impact as we provide a compatibility layer via ext/hash
(Thanks to Scott)We should keep this somewhere in Siberia like we did with other
extensions we removed. (PHP 4 XML stuff for instance)
I was not clear, sorry. There is no point to keep it in siberia as the
whole user API will still be available. You can see this move as a
dependency removal. libmcrypt is not used anymore and the ext/mhash
functions will be implemented using ext/hash, in ext/hash.
- Extension looking for love (if noone raises the hand, they will end
in PECL too)
- ncurses
I can help here for the windows port and pdcurses support on unix and
windows. Hartmurt agreed for the move it to pecl for 5.3.hm, I thought this was already done, go for it.
It will be done shortly.
- smnp
nice ext, any ISP out there willing to help? I can help for the windows supportLast time I checked it worked nicely and I know other user which have no
problems either, so I guess there's not much maintenance needed. The
only thing I see is implementing new parameter parsing API.So I don't see a reason to move it to PECL.
But who knows which minimum snmp version should be supported (I say
should not could)? What can I change on windows to support a decent
snmp version (don't look at the version we used now :)?
No one maintains it, the user base is relatively small (very small
even). We have moved working extensions to pecl in the past because
they were not maintained (and that's a very good reason). If you feel
like you can help to maintain it, please do it. As I said earlier, I
can give a hand to improve it and make it work smoothly on windows but
I can't do it alone.
Can be moved PECL
- interbase
- fpdf
- fbsql
- sybase and sybase_ct
Moving fpdf shouldn't be a problem, for the others I can't really judge,
I don't know a user of these, but that's me.
I'd to wait a couple of days but I think there is no issue to move them.
--
Pierre
- interbase
- fbsql
- sybase and sybase_ct
I think moving fbsql is quite reasonable. However interbase and sybase
I do not agree with.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
- interbase
- fbsql
- sybase and sybase_ct
I think moving fbsql is quite reasonable. However interbase and sybase I do
not agree with.
Who will maintain them? Who can we ask when there is issues (besides
the obvious ones)?
Cheers,
Pierre
On Sat, Jun 14, 2008 at 3:24 PM, Lukas Kahwe Smith
mls@pooteeweet.org wrote:
- interbase
- fbsql
- sybase and sybase_ct
I think moving fbsql is quite reasonable. However interbase and
sybase I do
not agree with.Who will maintain them? Who can we ask when there is issues (besides
the obvious ones)?
These extension seem widely used enough that we have to make it an
effort to support them. Removing them is removing a key feature our
user base experts to find. Now for PHP6 I see this a bit differently,
especially provided we have decent support for these databases via PDO.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi Lukas,
These extension seem widely used enough that we have to make it an effort to
support them.
If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?
That's why I doubt that these extensions are widely used. And if there
is users, they are in controlled environments like dedicated servers
or intranet and can then install them from PECL. If that makes you
feel better, I can make releases in PECL and post something about
their status.
Removing them is removing a key feature our user base experts
to find. Now for PHP6 I see this a bit differently, especially provided we
have decent support for these databases via PDO.
I don't see them as key features, and I doubt the PDO support will be
any better if no one actually care about them. It is even worst in the
case of firebird as even the firebird author(s) clearly stated what
they think about PDO and that they are not going to help (that's what
I understand).
Cheers,
Pierre
Pierre Joye wrote:
Hi Lukas,
These extension seem widely used enough that we have to make it an effort to
support them.If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?
I don't think this argument works very well. If we were to apply that
in general terms, we should probably drop Windows support completely
because there are pretty much no Windows users taking care of bugs, nor
sending patches. There are a couple, I don't want to make their
contributions seem insignificant, but the ratio of users to contributors
is terrible for the Windows platform.
For something like the SNMP extension, it works ok. SNMP isn't exciting
in any way. I did some work on it so it got to the point where it was
useful to me, and there have been a couple of requests over the years to
extend it, but I think for most people it does all it needs to do.
-Rasmus
Pierre Joye wrote:
Hi Lukas,
On Sat, Jun 14, 2008 at 4:26 PM, Lukas Kahwe Smith mls@pooteeweet.org
wrote:These extension seem widely used enough that we have to make it an effort
to
support them.If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?I don't think this argument works very well. If we were to apply that in
general terms, we should probably drop Windows support completely because
there are pretty much no Windows users taking care of bugs, nor sending
patches. There are a couple, I don't want to make their contributions seem
insignificant, but the ratio of users to contributors is terrible for the
Windows platform.
You are right, that's not a good argument. However I'm still not sure
about how it helps to have it in the core.
What if I release them through PECL of the current state and apply
patches or write fixes if there is reports and tests?
DLLs can be built as well using what we had in the last 5.2 releases.
That will make no difference for the users and will ease my work
(sorry to be egoist :).
For something like the SNMP extension, it works ok. SNMP isn't exciting in
any way. I did some work on it so it got to the point where it was useful
to me, and there have been a couple of requests over the years to extend it,
but I think for most people it does all it needs to do.
Agreed, that's why I made a call for love first and did not work well
so far. Maybe you can motivate Brian :)
Cheers,
Pierre
2008/6/14 Rasmus Lerdorf rasmus@lerdorf.com:
Pierre Joye wrote:
Hi Lukas,
On Sat, Jun 14, 2008 at 4:26 PM, Lukas Kahwe Smith mls@pooteeweet.org
wrote:These extension seem widely used enough that we have to make it an effort
to
support them.If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?I don't think this argument works very well. If we were to apply that in
general terms, we should probably drop Windows support completely because
there are pretty much no Windows users taking care of bugs, nor sending
patches. There are a couple, I don't want to make their contributions seem
insignificant, but the ratio of users to contributors is terrible for the
Windows platform.
I try!
And as I only use MSSQL, we should drop mySQL.
For something like the SNMP extension, it works ok. SNMP isn't exciting in
any way. I did some work on it so it got to the point where it was useful
to me, and there have been a couple of requests over the years to extend it,
but I think for most people it does all it needs to do.-Rasmus
--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hi Pierre,
Like I said on IRC, if the ext end up being broken, but remain in core
they can get fixed and made available easily to all users. If we move
them, then this is no longer possible. We can revist this topic for
PHP6, but I do not think we should start dropping these extension in
5.3.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
- interbase
- fbsql
- sybase and sybase_ct
I think moving fbsql is quite reasonable. However interbase and
sybase I do
not agree with.Who will maintain them? Who can we ask when there is issues (besides
the obvious ones)?These extension seem widely used enough that we have to make it an
effort to support them. Removing them is removing a key feature our user
base experts to find. Now for PHP6 I see this a bit differently,
especially provided we have decent support for these databases via PDO.
Apart from the problems created by changes made to the interbase driver in the
5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been
repaired :( ) the driver still works fine with modern builds of Firebird so
there as been no need to improve on it. Those of us who use it have not been
persuaded that PDO has any advantage as yet, especially when you add ADOdb in
as a back end, so there is NOT a suitable version of PDO for
interbase/firebird and no one is working on THAT, so PLEASE do not remove the
one package that is working well :(
As yet we have not identified any new functions in Firebird 2.1 that can not
still be accessed via current driver, so there has not even been a need to
spend time building an environment in which we can compile our own copies. The
binary versions supplied in Linux and Windows simply work.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi Lester,
Apart from the problems created by changes made to the interbase driver in
the 5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been
repaired :( ) the driver still works fine with modern builds of Firebird so
there as been no need to improve on it. Those of us who use it have not been
persuaded that PDO has any advantage as yet, especially when you add ADOdb
in as a back end, so there is NOT a suitable version of PDO for
interbase/firebird and no one is working on THAT, so PLEASE do not remove
the one package that is working well :(
You need it? Please help me to maintain and to provide reliable
binaries for windows or to keep it up to date when necessary (given
your comment below).
As yet we have not identified any new functions in Firebird 2.1 that can not
still be accessed via current driver, so there has not even been a need to
spend time building an environment in which we can compile our own copies.
The binary versions supplied in Linux and Windows simply work.
We are very reluctant to continue to release binaries where we have
zero ideas how we can update the dependencies without breaking
anything in the extension or in the end user applications. I would
have no problem to keep it and even to help to maintain it if (and
only if) I have someone knowing firebird and its php drivers well
enough to tell me if what I did works or not.
It is nice to complain how useless is PDO but it is way better to
actually contribute and help us to make your software working with PHP
:)
Cheers,
Pierre Joye wrote:
Hi Lester,
Apart from the problems created by changes made to the interbase driver in
the 5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been
repaired :( ) the driver still works fine with modern builds of Firebird so
there as been no need to improve on it. Those of us who use it have not been
persuaded that PDO has any advantage as yet, especially when you add ADOdb
in as a back end, so there is NOT a suitable version of PDO for
interbase/firebird and no one is working on THAT, so PLEASE do not remove
the one package that is working well :(You need it? Please help me to maintain and to provide reliable
binaries for windows or to keep it up to date when necessary (given
your comment below).
WHEN there is a need to maintain it the Firebird Foundation could be persuaded
to do so, the ONLY need for maintenance at the moment ids to fix bugs
introduced BY the continuing unnecessary changes in each build of PHP.
As yet we have not identified any new functions in Firebird 2.1 that can not
still be accessed via current driver, so there has not even been a need to
spend time building an environment in which we can compile our own copies.
The binary versions supplied in Linux and Windows simply work.We are very reluctant to continue to release binaries where we have
zero ideas how we can update the dependencies without breaking
anything in the extension or in the end user applications. I would
have no problem to keep it and even to help to maintain it if (and
only if) I have someone knowing firebird and its php drivers well
enough to tell me if what I did works or not.It is nice to complain how useless is PDO but it is way better to
actually contribute and help us to make your software working with PHP
:)
I would be more than happy to look at working on a PHP6 build of the
interbase driver tailored to the UNICODE build of Firebird 2.1. That is once
someone actually decides the base will be fore PHP6. I even installed a
development build of PHP6 some time ago, but if there is going to be TWO
versions of PHP6 then to be honest I am not interested. As soon as I can be
sure that we have one base for PHP6 then I will return to that development,
but PHP5.3 is just another totally unnecessary distraction. I have now got
php_interbase restored on PHP5.2.x so is there any need to bother my customers
with PHP5.3 - no. I'll wait now for PHP6 .....
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Lester, hi,
I even installed a
development build of PHP6 some time ago, but if there is going to be TWO
versions of PHP6 then to be honest I am not interested.
There haven't been for the last couple of weeks. We're just waiting for
Scott to finish with the Engine work so that we can commit the rest and make
PHP core (and the core extensions) be always-on Unicode.
As soon as I can be sure that we have one base for PHP6 then I will return
to that development, but PHP5.3 is just another totally unnecessary
distraction.
PHP 5.3's our baby!!!!
I have now got
php_interbase restored on PHP5.2.x so is there any need to bother my
customers with PHP5.3 - no. I'll wait now for PHP6 .....
Poor customers. They'll miss all the benefits without the inevitable
performance loss.
As far as I'm aware there's nothing in PHP 6 that can't be supported from
PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of developers will
like.
- Steph
--
Lester Caine - G8HFLContact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Steph Fox wrote:
As far as I'm aware there's nothing in PHP 6 that can't be supported
from PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of
developers will like.
AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN UNICODE
STABLE SYSTEM AVAILABLE TODAY !!!!!!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi Lester,
Am Samstag, den 14.06.2008, 21:13 +0100 schrieb Lester Caine:
[...]
AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN UNICODE
STABLE SYSTEM AVAILABLE TODAY !!!!!!
Please, don't yell. KTHXBYE
cu, Lars
As far as I'm aware there's nothing in PHP 6 that can't be supported from
PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of developers will
like.AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN
UNICODE STABLE SYSTEM AVAILABLE TODAY !!!!!!
Please don't shout, thanks, I'm nursing a headache.
Most of it was developed in CVS HEAD, and then back-ported to 5_3 when it
became clear that Unicode support is likely to take a while. Extensions
don't tend to be developed that way (ever), because the PECL system is such
that whatever's in CVS HEAD needs to work with the current release. But
that's all changing too.
- Steph
Pierre Joye wrote:
You need it? Please help me to maintain and to provide reliable
binaries for windows
This statements makes it sound like extensions that do not build on
Windows should be removed. That sounds insane to me. Please elaborate.
I must not understand what you are trying to say. I could care less
if any of PHP works on Windows. I am sure Richard feels the opposite. =)
--
Brian Moon
Senior Developer/Engineer
When you care enough to spend the very least.
http://dealnews.com/
Pierre Joye wrote:
You need it? Please help me to maintain and to provide reliable
binaries for windowsThis statements makes it sound like extensions that do not build on Windows
should be removed.
That sounds insane to me. Please elaborate.
No, the statement is about no one actually being able to maintain it,
to solve possible issues or to answer questions about the code or how
it works. Making any change a possible breakage.
But the important point in my reply was my question :):
You need it? Please help me to maintain (it) and to provide reliable
binaries for windows
The binary part is only a good side effect of having a maintained extension.
I must not understand what you are trying to say. I could care less if any of PHP
works on Windows. I am sure Richard feels the opposite. =)
Now, to be honest, I don't care if 95% of our developers do not care
if PHP does not work on Windows. 99% of them will be the first to ask
to fix things as soon as users report issues or missing extensions.
But what you say is a good example on how we may act. Why should we
care for something we don't need? Because you need it? :)
Cheers,
Hi,
Can be moved PECL
- interbase
- fpdf
- fbsql
- sybase and sybase_ct
Sybase can be moved, it is unmaintained. I would've done this long ago if I
could, karma-wise.
Sybase_ct works perfectly for us at 1&1 and despite feature requests that
exist and me not having put big efforts into it over the past years it
serves millions of requests a day without problems. The next big step would
be to add all the if (unicode)-stuff needed for PHP6 and/or to port it to
a PDO driver, which I frankly don't have time to do.
If an extension is moved to PECL, it is a bit more of a hassle to install
it: Windows: instead of enabling it in php.ini you need to download the dll
(not sure who builds that? Is it done automatically?) / Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't work for
me, must've been some wrong auto-whatever). Plus I'm not sure how developing
works, would you mess up your PHP checkout tree by copying the pecl/ext/XXX
to php-src/ext/XXX and the running all these magic autotools? Correct me if
I'm wrong here, but I guess that's what people on both sides - extension
developers and PHP users - are afraid of when you announce PECL-moves,
right? Before you say "PECL is not siberia" think about the following: If
PECL moves wouldn't hurt the user experience for any partys involved, why
would any extension live in php-src/ext/?
- Timm
hi Timm,
Hi,
Can be moved PECL
- interbase
- fpdf
- fbsql
- sybase and sybase_ct
Sybase can be moved, it is unmaintained. I would've done this long ago if I
could, karma-wise.
Let see what other thinks about this one, I'm waiting a couple of days more.
Sybase_ct works perfectly for us at 1&1 and despite feature requests that
exist and me not having put big efforts into it over the past years it
serves millions of requests a day without problems. The next big step would
be to add all theif (unicode)-stuff needed for PHP6 and/or to port it to
a PDO driver, which I frankly don't have time to do.
And same for us. We don't the time or resources to support them (see below).
But if we work together, it should be possible to keep them. Let me
ask you the same than I ask to Lester, will you help us to keep
sybase_ct in php-src? You don't need to know C or php internals but to
actually provide tests and run them when we update the libraries or
releases RC. What would rock is to have it supported by gcov (by us or
somewhere else with a public report), would it be possible?
If an extension is moved to PECL, it is a bit more of a hassle to install
it: Windows: instead of enabling it in php.ini you need to download the dll
(not sure who builds that? Is it done automatically?)
It was done automatically and without much checks and tests but users
feedbacks after the releases. There is no need to say that it is not a
good way to do it.
Our position is that a dependency should be reliable, testable and
easy to update. That means that people should be able to test if a
dependency update or a change in the extension build/code did not
break anything. As we can do it easy for extensions with a large tests
suite or widely used, it is an impossible task for extensions like
sybase or interbase.
/ Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't work for
me, must've been some wrong auto-whatever).
If the release is done correctly, a simple pecl install sybase works.
Cheers,
Pierre
Hi,
But if we work together, it should be possible to keep them. Let me
ask you the same than I ask to Lester, will you help us to keep
sybase_ct in php-src? You don't need to know C or php internals but to
actually provide tests and run them when we update the libraries or
releases RC.
There is a (small) number of tests:
http://cvs.php.net/viewvc.cgi/php-src/ext/sybase_ct/tests/
I can look into setting up a "cruise-control"-like infrastructure on our
dev-machines that'll run these periodically.
What would rock is to have it supported by gcov (by us or
somewhere else with a public report), would it be possible?
How can I get this done?
- Timm
But if we work together, it should be possible to keep them. Let me
ask you the same than I ask to Lester, will you help us to keep
sybase_ct in php-src? You don't need to know C or php internals but to
actually provide tests and run them when we update the libraries or
releases RC.There is a (small) number of tests:
http://cvs.php.net/viewvc.cgi/php-src/ext/sybase_ct/tests/I can look into setting up a "cruise-control"-like infrastructure on our
dev-machines that'll run these periodically.
Thanks for the offer, that would be very helpful. Is it possible to
have it for windows as well? It could also help if we can get one
access to fix the possible bugs, as I don't have any sybase licenses
or access to any kind of Sybase server (other developers neither).
What would rock is to have it supported by gcov (by us or
somewhere else with a public report), would it be possible?How can I get this done?
I'm adding Nuno to the loop, he is the one leading the gcov initiative
and will surely explain the setup in a better way than me :)
Grüße,
Pierre
Hi,
been busy again at work, sorry for the late answer.
I can look into setting up a "cruise-control"-like infrastructure on our
dev-machines that'll run these periodically.Thanks for the offer, that would be very helpful. Is it possible to
have it for windows as well? It could also help if we can get one
access to fix the possible bugs, as I don't have any sybase licenses
or access to any kind of Sybase server (other developers neither).
I think it could be done on Windows also - let's see if my budget allows for
a Windows testing machine - if not, I'll (shhhhhh) use the production
server:)
- Timm
/ Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't
work for
me, must've been some wrong auto-whatever).If the release is done correctly, a simple pecl install sybase works.
This is an important point because unfortunately in the past a "moved
to PECL" was theoretical. Instead, if it meant the moved extension
could be found at pecl.php.net/extname, have its own bug category, and
be installable via the pecl command... the word "PECL" would be a lot
less scary. And it's worth noting that Pierre will release the
extensions mentioned in this thread so they won't be hidden in the
pecl CVS module.
And on a related note, have we considered any sort of fetch
integration with configure? You know, like --with-apc would grab it
much like 'pecl download apc' does today. Or more likely a trigger,
like --with-apc=fetch,beta ... you get the idea. A friendlier this[1].
Regards,
Philip
Pierre Joye wrote:
Can be moved PECL
- interbase
- fpdf
- fbsql
- sybase and sybase_ct
Please let me know if you can either help to maintain an extension or
if you see any issue with one of these moves.
i can help with fpdf if needed but it should go to PECL
nonetheless ...
--
Hartmut Holzgraefe, MySQL Regional Support Manager EMEA
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering