CO-process

[aotto2 at my-deja.com]

Hi,


> >
> > > heavyweight for many of the things you'd want to use .net for.
> >
> >   1) the solution for MqSeries has only 20 KB wich isn't
heavyweight.
>
> I was thinking more of IPC time than memory use.

  In fact the CO-Process architecture is in most cases faster,
  because you write the CO-Process in the language who is fit best
  to the problem and you don't have to step into , for example,
  TCL details.

  If you just take MqCon.

   MqGet that is the listener of MqSeries wand ill be mostley called
   in some kind of while loop to wait for messages.
     1) How TCL event handling works with the MqSeries while loop
        if both are running in the same process ?
        You have to fit both together which mean this is a very
        terrible work and the solution will be definit slower
        than a CO-Process
     2) In fact if you really step down real world problem's
        and start thinking in CO-Process like manner you find
        out that in most cases the transport of the JOB through
        STDIN to the CO-Process is not the *time* problem.
     3) There are some cases which will most benefit from Free.NET
         - message technology ( MqSeries,... )
         - database connection ( sybase, oracle, db++ .. )
         - gui programming
         and a lot more ...
>
> >   2) One CO-Process is used to manage one "task" ( DB, Communication
> >      GUI-Interface, Appl-Server, ...) there is no need to write
> >      one task in more than one language, the benefit is that you
> >      can choose the right language for the task, and the clear
> >      and easy interface between the tasks
>
> That was my impression. As I wrote before, this is fine for what it
> is, but does not match up feature-by-feature for what .net is offering
> (on paper, anyway).
>

 you should not forget the Microsoft .net is just a paper
 and Free.NET you can download this is in fact a huge difference.
 Free.NET offers you a technology which is *easy* to understand
 *easy* to use and able to handle *multi* language needs, this is real
 a big step in the right direction without even learning 1000's of
 interface procedures, subroutiens, classes. If you just look to
 tcl, perl and python everybody tries to write his own DB, GUI, ..
 interface and everybody have to update his interface with every
 new (language)release comming out. Which is an big waste on man-
 power and a big waste on future. If you look to MqCon a perl guy
 will be able to write an perl interface in less than 3 days and
 this interface will not be changeed with every (language)release.


mfg

  aotto :)



Sent via Deja.com
http://www.deja.com/