[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dsdp-tm-dev] RE: Extending RSE
|
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.
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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