Rick,

thank you very much for your answers and insights!

---rony


On 05.07.2016 23:04, Rick McGuire wrote:
>
>
> On Sat, Jul 2, 2016 at 11:44 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at
> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
>     Changed the subject to reflect this thread of discussion.
>
>     The desire of many: allow ooRexx to be run off an USB stick to show 
> off/demonstrate ooRexx to
>     others and/or have a great tool on ones hands to bring along when 
> checking out problematic
>     computers or helping collegues and friends.
>
>     Currently this is not possible on computers, where the user has no 
> superuser power over the
>     computer, which is a great pity. This scenario is quite usual, when 
> computers are deployed in
>     business environments, where root/superuser power is reserved for the 
> installation,
>     maintenance teams and the like.
>
>     The reason for this restriction seems to be how rxapi gets started and 
> used.
>
>     So maybe a few questions therefore about rxapi:
>
>       * What is the rationale of allowing only one rxapi running per computer?
>
> This is largely a throw back to how the original OS/2 version, but there are 
> other limitations
> that could make it difficult design (see below).  
>
>      *
>
>
>       * What is the rationale to allow to install it with root/superuser 
> rights only?
>
> David Ashley did all of that work, but my understanding is it was driven by 
> linux conventions for
> daemons that are launched at system boot. The rxapi server is quite capable 
> of being launched on
> demand, but it is still limited to one instance per system. 
>
>      *
>
>
>       * Would it be theoretically possible to run separate instances of rxapi 
> for different user
>         sessions (one per session) by default, one may be a 
> root/superuser/daemon session?
>
> The current design uses a classic tcp client/server architecture for handling 
> requests. The server
> listens on a known port and each new process where Rexx is running 
> establishes a connection to the
> server using the defined port. The server spins of a thread to service each 
> connection and all
> messages between the client and server are sent on that connection. I don't 
> know of any way using
> tcp for a different listener port to be used for each user and for the 
> clients run by that user to
> discover the port used by its server. 
>
> There may be other possible ipc mechanisms that could be used, but I'm not 
> aware of them. 
>
> Rick
>  
>
>      *
>
>
>     Ad port number: even though there is a reserved port for ooRexx, this 
> does not guarantee that
>     it would be available at all on any computer. So in the case of a port 
> clash (port already in
>     use by a different program at rxapi startup) communicating the rxapi port 
> to Rexx clients
>     needs to be done one way or the other.
>
>     Ad users killing rxapi and thereby affecting running ooRexx programs in 
> multiuser
>     environments: this would be possible for sudo users at all times and 
> doing it is even
>     mandatory for upgrading ooRexx currently. (In a normal use case of ooRexx 
> programs, users
>     would not even know about rxapi so would not know to kill it.)
>
>     ---rony
>
>     P.S.: Even if this is not tackled for 5.0, it would help deciding changes 
> for the future, if
>     more information was available about the rationales behind rxapi. It for 
> sure would help
>     spreading the word about ooRexx by demonstration of its capabilities 
> tremendeously.
>
>
>     On 01.07.2016 16:57, René Jansen wrote:
>>     Hi Erich,
>>
>>     I’ll work on trying to get these packages available, at least the ones 
>> that Erico does not
>>     provide.
>>
>>     Yes, we should not change anything for this release. I entirely agree. 
>> Still, I am not
>>     convinced that ooRexx needs a designated port at all; much less a deamon 
>> process running as
>>     root. But we will study and discuss in due time.
>>
>>     I’ll try to fix the Z installation. Did not know about the rexx.cat 
>> <http://rexx.cat> bug. 
>>     Indeed, file rexx.cat <http://rexx.cat> now reports: 
>>     rexx.cat <http://rexx.cat>: Nazgul style compiled message catalog, 
>> version 1
>>
>>     instead as data what it used to do.
>>
>>     best regards,
>>
>>     René.
>>
>>
>>>     On 1 jul. 2016, at 16:45, Erich Steinböck <erich.steinbo...@gmail.com
>>>     <mailto:erich.steinbo...@gmail.com>> wrote:
>>>
>>>     afaik that is done with cpack and documented in Cmake-build-readme.txt
>>>     Thanks for the pointer.  These package files are exactly what we should 
>>> make available to
>>>     our users for beta-testinI do not know the cross-process requirements 
>>> of rxapi
>>>     rxapi listens on port 10010.  It is a system-wide demon - there can 
>>> only be one demon
>>>     listening on port 10010.  10010 is the official port for ooRexx,
>>>     see 
>>> https://en.m.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Well-known_ports
>>>
>>>     how could we localize that, possibly running over different port 
>>> numbers or just
>>>     sockets/pipes localized to the user
>>>     I cannot imagine anyone doing a change of this magnitude - we really 
>>> should push for beta
>>>     and then release
>>>
>>>     I also looked at the Z build - could you tell me why this is related to 
>>> running from the
>>>     build dir?
>>>     the test is running off build/bin, but the rexx.cat <http://rexx.cat> 
>>> it sees, is from an
>>>     older "make install" version.  We had a bug concerning how rexx.cat 
>>> <http://rexx.cat> was
>>>     being built, that I just recently fixed - that's why the two versions 
>>> are different and
>>>     that's why a few tests fail, which check for exact message texts
>>>     There may be other things that are being picked up from an installed 
>>> rexx when running from
>>>     build/bin, but I haven't checked that
>>>
>>>     Erich
>

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to