[dsdp-tm-dev] RE: Extending RSE

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hello Florian,

 

Thanks for your interest!

• The difference of rlogin and rsh is very small, and I also don't fully understand it. Read up on Wikipedia and/or the publicly available manpages. My feeling is that rlogin provides an interactive session (with terminal emulation) whereas rsh is for noninteractive single commands. If this is true, then you'd want to rlogin. But I may be wrong.
• FYI, it would be very interesting if you could also implement a file service based on rcp in addition to your shell / terminal service based on rlogin. This has long been requested, see bug 213438 [1] which is related. A file service is MUCH more difficult than plain shell access, because you'd need to run commands like "ls" on the remote and interpret the listing output - the bug has more info on that.
• rlogin only provides a shell and no file transport, so it's similar to telnet except that user authentication (password) is simpler with rlogin. I'd recommend that you start with the telnet service which should be very VERY simple to adapt because it's also using commons net already. Also, session concept is similar in tellnet -- you need a new connection each time.
• On subsystem vs service: An RSE "subsystem" is for completely new kind of thing e.g. file management vs. interactive shell vs. terminal vs. process list. In your case, you want an interactive shell, so the subsystem already exists in RSE and you don't need to reimplement it. All you need to do is provide your service, i.e. the communication mechanism to drive the existing subsystem which already has views (RSE Terminals and RSE Command View). Does this help? If you could point us to the place where you are missing this kind of explanation, I think we should add it.
• On freelance vs. employed - this should be no problem, as long as your employer allows you to continue working on the project, and give away (i.e. license) the sources under the EPL. As a freelancer, you own the sources but while employed, typically your employer (company) owns the sources so they must be OK with contributing to Open Source.

On a different note, you just sent E-Mail to dsdp-tm-dev-owner (which is me only), next time please send to the whole mailing list (dsdp-tm-dev@xxxxxxxxxxx).

 

Welcome, thanks again for your interest, and feel free to ask the mailing list if you have any more questions.

 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=213438

 

Thanks,

--

Martin Oberhuber, Senior Member of Technical Staff, Wind River

Target Management Project Lead, DSDP PMC Member

http://www.eclipse.org/dsdp/tm

 

 

---

From: mailman-bounces@xxxxxxxxxxx [mailto:mailman-bounces@xxxxxxxxxxx] On Behalf Of Florian Guillochon
Sent: Freitag, 29. Mai 2009 15:37
To: dsdp-tm-dev-owner@xxxxxxxxxxx
Subject: Extending RSE

Hi,
I am a young french student, and I'm considering extending the RSE (beautiful product by the way !) in order to support the rsh protocol.
I've been reading RSE help to understand the structure (services / subsystems ...) of the project, and i've been poking my nose in the tm mailing list to be informed of its advancement.
Here are two points which leave me confused and I'd be please if you could provide me a little help.
- To minimize the effort, I thought about adapting existing protocol sources. Which one do you advise me to consider (telnet, ssh ...) ?
- I've seen the term 'rlogin' used rather frequently (the Apache Commons Net provide an RloginClient too), should I develop an rsh subsystem or a rlogin one ?
- Through the RSE developer guide tutorials (create a subsystem configuration), the concept of service is kind of eluded. On the other hand, the telnet sources clearly implement a new service. Do you have any more tips about implementing a new subsystem and a new service ?

On a whole other subject, I'm currently in placement, and this extension will be profitable for my employer. As we have not yet decided if this solution will be adopted or not, I was thinking about beginning the development in freelance, and if necessary, pursuing it under the name of the company. Does it raise any problem ?

Thank you for your attention,

Florian Guillochon