It depends what effort you plan to invest into testing and debugging. ;-)
Missing pieces:
- Documentation.
- SSL on win32.
- Consistent error handling and error recovery.
- Pascalscript import units for complete MSEgui.
- MSEifi webbrowser plugin.
- Some convenience tools in MSEide for MSEifi project handling.
As I pointed out, we (on the long run) have to do two projects which
include remote a GUI.
(1) Server done in Delphi running on a dedicated PC, no chance to
install any non-standard software on the "Terminal" or use any
non-standard protocols
(2) Server is an embedded device, software done in Free Pascal, there
can be our software on the "Terminal", protocol: any kind of TCP/IP.
I feel that MSEifi might help doing (2), as it needs software (at least
a dll for the plugin) installed on the Terminal.
So I suppose I don't need SSL, Pascalscript and a browser plugin.
Regarding convenience tools: This project is not going to be started
soon. It's an add-on for a Linux based embedded device that we are
planning. First the hardware and the main function is to be crafted,
this add-on will be the second step. And this step includes porting the
Free Pascal compiler to the NIOS CPU (unless this is done by somebody
else before we can start).
Before I knew about MSEifi I intended to attach the remote GUI on a
"per-control" base via a propriety protocol (e.g. using RemObjects). But
this would imply handling any program done that way individually, which
of course is not really desirable. Do you think MSEifi will help ?
An additional consideration is to provide a miniature remote GUI for the
primary firmware (done in ANSI C) of the device in a way consistent with
the GUI planned for the future Pascal add-on. Do you think MSEifi will
help with that ?
MSEide is GPL, MSEgui and MSEifi use the same modified LGPL license as the FPC
RTL. The code is on Sourceforge:
http://sourceforge.net/svn/?group_id=165409
Sounds good !
During my investigations on open source software licenses I heard about
some drawbacks when using LGPL code in embedded devices (it might be
problematic to provide the requested support for the users to upgrade to
a new version of the LGPL'ed libraries when statically linking, which is
why sometimes it's recommended not to use the µCLinux version of glibc).
But I do think this should be solvable, as I don't think it's intended
by the FSF and the individual copyright holders to prevent the use of
LGPL'ed code in embedded devices, only because they don't have an MMU
and thus don't support .so's.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
