I kinda like Mike's suggestion, to have a new set of functions to
support IP6. Now if the newer IP6 stuff can work correctly in IP4 or
IP6 then I think we have a winner. Existing stuff would continue to work
under IP4, and when an applications code is converted to use the new IP6
functions it might still work in an IP4 only environment. Have a newer
set of functions also addresses Mark's comment of being more object
oriented, rather than "procedural"...
That way I do not have to change the ooRexx programs that I have already
written that use IP4.
When I want to support IP6, I can modify the code as needed to make use
of the newer IP6 support. With separate libraries, as a designer, I can
choose which way I want to go....
I see some problems with requiring a newer version of ".net", because I
know of a number of companies that are not ready to convert to newer
releases beyond WINXP, even though they will not have any official
"support". Sometimes, this is a financial issue (new hardware, new
software, training, etc.), and in other cases it is because they do not
have the staff to oversee an orderly conversion.
Requiring a newer version of .NET might make some applications to be not
available on an older system and/or a older application to not be
available on a newer version of Windows. You also have the "special"
case of anybody who uses WINXP under a virtual machine to support
applications that have not been converted to a newer Windows environment
(or that are not available under Linux).
Compatability issues can be, and frequently are, complex - For Instance,
I have found a number of little applications that say they work under
Windows 8.1 - and they don't, unless the target system has a real touch
screen - particularly error message pop-up screens that are longer then
the laptop's screen height with an "OK" button at the bottom of the
window.... With a touch screen you can "slide" the window up, but
unless the designer provided for the old scroll bars as well, you can't
scroll the windows with your mouse or cursor buttons.
This also applies to Linux environments, which as we know, are not all
the same... i.e. Ubuntu's newer screen manager environments...
or Gnome 2 -vs- Gnome 3 -vs- KDE - vs- whatever.
My vote? consider doing the IP6 under a newer set of functions.
/s/ Bill Turner, wb4alm
On 02/11/2014 11:06 AM, Mike Cowlishaw wrote:
One of the thoughts I had before David posted the beginning of
this thread is that maybe we could use this opportunity to update
rxsock itself, so that it better uses the newish APIs and is
object orientated than rather than procedural.
Upwards-compatible could be tricky.
Maybe just add a new library ('rxsock6'?) which is unencumbered by
past history.
Mike
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
