You are not logged in.

Dear visitor, welcome to KDE-Forum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Wednesday, June 7th 2006, 5:57pm

New KomunicationKonduit idea

Ok... So I have been using KDE for a long time now and find it a very productive work environment. I have however hit a wall with a new problem. I want to use my version of kdevelop to edit my source code which is sitting on a remote server. Now of course I can open it using the fish KIO_slave but that limits my functionality since I can not actually call the compiles from my kdevelop since it will try to execute it from here. The build environment is very complicated on the remote system and does not correspond to a standard gnu/gcc type env, we dont even use automake. Anyway... To the idea...

So, I can remotely mount the filesystem using sshfs which will make it look more local but now the issue rests with running gmake. So, enter KomunicationKonduits. What if there existed a wrapper that would encapsulate calls like system, exec, and so forth, such that it ran the call remotely and then passed the exit code and the output back to the local system. The class could have several different backends corresponding to different low level communications protocols, the initial of course being the ssh and local backends. The class could hold a persistant connection open so that if any environment (ie. the build environment) can be maintained. So.. Instead of calling a program like the following:

int ret = system("gmake myanalysis.all");

One would use the following...

int ret = konduit.system("gmake.myanalysis.all");

Where konduit was of type KomunicationKonduitSSH. Is this crazy?
This could be used in any application that needs to call third party apps.

Justace

This post has been edited 1 times, last edit by "prophecy" (Jun 7th 2006, 6:09pm)


jezz

Beginner

Posts: 2

Location: Paris

  • Send private message

2

Thursday, June 8th 2006, 7:20am

RE: New KomunicationKonduit idea

Ok, so you want main part of your program executed on a remote host, but all graphics part executed on local host? I think it already exist something like this. It is called "remote X server".

More seriously, how to choose which process should be executed on local host and which executed on remote host? It is so much complex.

IMHO, the best way is to allow user to change scripts executed by kdevelop. And change "make" to "ssh host -c 'make'". But, do not touch on lower layers of kdelibs.
--
Jérôme Pouiller (Jezz) <jerome.pouiller AT gmail.com>

3

Thursday, June 8th 2006, 7:25am

I started to play with just this idea. I agree it could easily get confusing. The problem is with the output redirection. I just can not seem to get past it. I was trying to hack something together locally here to play with but had to get back to work. It is simple really... For each third party app include this backend you want to use and the command. Pretty stright forward. The system would default to local which would essentially be a pass through.

I was waiting for somebody to mention remote X. Well, that is just not an option. The remote environment is locked down and I has very old software on it. To get the features of the new kdevelop I would have to install an entire kde tree there (well only kdelibs and kdebase + devel tools) but still you get the idea. It would be quite a chore and then this idea came to me as a possible solution.

Justace

jezz

Beginner

Posts: 2

Location: Paris

  • Send private message

4

Thursday, June 8th 2006, 8:00am

Quoted

Originally posted by prophecy
I started to play with just this idea. I agree it could easily get confusing. The problem is with the output redirection. I just can not seem to get past it. I was trying to hack something together locally here to play with but had to get back to work. It is simple really... For each third party app include this backend you want to use and the command. Pretty stright forward. The system would default to local which would essentially be a pass through.

I don't understand what goes wrong. Interaction with ssh command i/o should work fine. This kind of commands (simulating a remote command and local kdev i/o) work:

Source code

1
echo "interaction" | ssh -T host 'read A; echo $A' | grep interaction

no?

Quoted

Originally posted by prophecy
I was waiting for somebody to mention remote X. Well, that is just not an option. The remote environment is locked down and I has very old software on it. To get the features of the new kdevelop I would have to install an entire kde tree there (well only kdelibs and kdebase + devel tools) but still you get the idea. It would be quite a chore and then this idea came to me as a possible solution.

sure
--
Jérôme Pouiller (Jezz) <jerome.pouiller AT gmail.com>

5

Thursday, June 8th 2006, 4:32pm

Ok, one thing that should be stressed is that my remote build environment requires and expensive, as in time and resources, setup each time you log in. So I need something persistant. So, maybe I really just need to hack something together. I just thought that if there was a backend builtin for something like this it would be cool and might bennefit others.