[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [geclipse-dev] LFC support: Light at the end of tunnel
|
Hi,
For me it is quite clear that we definitely should avoid system dependent code whenever possible. Of course we already have such code but actually this is no code coming from us but from third parties (like opengl or vtk). Non of our plug-ins currently introduces platform dependent code itself. Therefore I strongly vote for avoiding LFC access via system dependent calls.
My proposal would be the following. Have a look at the source code of the gLite LFC UI commands and try to find out how the corresponding protocol works. After that provide a pure Java implementation for that protocol. I did this for the VOMS protocol and it was not that hard, at least if you are able to read C/C++ code. Of course the LFC might be more complicated. Nevertheless it should be absolutely possible to reproduce the C/C++ code within out framework in pure Java. Everything else reduces to networking...
Cheers, Mathias
-----Ursprüngliche Nachricht-----
Von: geclipse-dev-bounces@xxxxxxxxxxx [mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im Auftrag von Kornmayer, Harald
Gesendet: Montag, 30. Juli 2007 16:57
An: Developer mailing list
Betreff: AW: AW: [geclipse-dev] LFC support: Light at the end of tunnel
Are there comments from other developers?
Harald
>>-----Ursprüngliche Nachricht-----
>>Von: geclipse-dev-bounces@xxxxxxxxxxx
>>[mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im Auftrag von
>>Mateusz Pabis'
>>Gesendet: Montag, 30. Juli 2007 15:04
>>An: Developer mailing list
>>Betreff: Re: AW: [geclipse-dev] LFC support: Light at the end
>>of tunnel
>>
>>
>>Kornmayer, Harald pisze:
>>> Well!
>>>
>>> Is that what we really want to use? We should be carefull
>>not to overload the
>>> g-Eclipse framework with every "system dependent" UI
>>installations. Do we
>>> distribute it with this windows UI? Then we should put the
>>linux UI as well for
>>> the linux folk? And the poor Mac users?
>>>
>>> As I understand this, it is just a "wrapper" for UI command
>>line comands.
>>> And it does not rely on any WS implementation. But may be I'm wrong!
>>>
>>
>>Yes, this is just a wrapper for UI commands. But commands as
>>*.exe files
>>are provided. I'm contacting the authors to obtain some useful hints
>>(hopefully they'll be helpful).
>>
>>Well, this is what I wanted to raise:
>>MacOS-X is somehow linux like, isn't it? So maybe we're able to run UI
>>commands also on Mac. Except for Marcin's computer he won recently and
>>iPod Apple is not popular in Poland ;-)
>>
>>So, we have to decide if we can relay on this UI commands.
>>Note: we don't have to have full list, just this LFC related.
>>
>>We are already distributing platform dependent plugins (for
>>vtk? opengl?).
>>
>>I have in mind that this is not a good solution. That's why I vote 0
>>(zero) and I hope somebody else will decide ;-)
>>
>>Why I posted this link was to show there is UI port to
>>Windows, I don't
>>want to use any part of the GUI/wrapper - just the command line tools.
>>
>>--
>>Mateusz Pabis
>>_______________________________________________
>>geclipse-dev mailing list
>>geclipse-dev@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/geclipse-dev
>>
_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
