ANNOUNCE: libmsgque2.3-beta1
Andreas Otto
The libmsgque project is an infrastructure for linking applications together
to act like a single application. This is done using Unix or inet domain
sockets. The framework handles all aspects of setting up and maintaining
the link in addition to starting and stopping the different applications,
starting and stopping the communication interface, sending and receiving
packages, reading and writing data from or into packages, setting up and
maintaining the event handling for asynchronous transfers, and propagating
warnings or errors.
WHERE TO GET
============
As usual, it is available from:
http://libmsgque.sourceforge.net/
http://sourceforge.net/projects/libmsgque/
WHAT'S NEW
==========
This is the initial announcement
WHAT IS IT
==========
First of all it is a framework to link client with a server.
To get more information's please use the following links:
1. an overview about the basic concept:
http://libmsgque.sourceforge.net/overview.htm
2. the man page of the tclmsgque extension:
http://libmsgque.sourceforge.net/tclmsgque.htm
Regards,
Andreas Otto (aotto1968)
Alexandre Ferrieux
> ANNOUNCE: libmsgque2.3-beta1
After reading the overview above, I'm still lost about what problem
your framework solves.
More precisely, the following statement (about shell pipelines):
> The data send through the pipeline are strings and every
command in the pipeline
> have to parse the string output of the previous command to
extract the information's needed.
strikes me as utterly wrong.
Nobody prevents you from writing data in binary form in a pipe (random
example: gzip).
Now you're saying that in cmd1 @ cmd2 @ cmd3, all the cmdX are
separate processes; hence,
whatever complicated operations take place in between, there is inter-
process communication, that is data copy from one address space to
another. This is exactly what happens in cmd1 | cmd2 | cmd3 with
binary I/O. (the only more "efficient" transfer I know of being, on a
single host, with shared memory or a common mapped file -- but this is
much harder to keep clean than pipes).
So... why should one use this library ?
-Alex
Andreas Otto
Hi,
I'm well known to write software nobody uses and nobody understands :^)
basically .. does you know Microsoft Powershell ?
to say it in easy words ... this does the same as MS PowerShell...
but I think "a little bit smarter"
The basic idea was to replace the good old shell PIPE based on STRINGS
with something better.
If you download and build the distribution you get in the "acmds"
directory a set of executables. These executable can be used to play
with:
example:
cat /etc/passwd | asplit -d ":" @ asort -2 I @ acut -f 0,2,3 @ \
ajoin -d ' | ' -0 "%-15s" -1 "%-5i" -2 "%-5i"
and the tests directory is good source for additional example like
a tcl server: http://libmsgque.sourceforge.net/tcl_server.htm
or just read the tclmsgque web page:
http://libmsgque.sourceforge.net/tclmsgque.htm
mfg
Andreas Otto
Alexandre Ferrieux
> Alexandre Ferrieux wrote:
> > More precisely, the following statement (about shell pipelines):
> > Nobody prevents you from writing data in binary form in a pipe (random
> > example: gzip).
>
> I'm well known to write software nobody uses and nobody understands :^)
> basically .. does you know Microsoft Powershell ?
> to say it in easy words ... this does the same as MS PowerShell...
> but I think "a little bit smarter"
> The basic idea was to replace the good old shell PIPE based on STRINGS
> with something better.
Say, are you a troll ?
Or maybe a computer program taking the Turing test ?
(in which case I have to tell you, you failed)
I won't repeat my arguments and question.
I'm still expecting an anwser.
-Alex
Georgios Petasis
I don't know about other software, but I still remember your
(unfinished?) tcl compiler :-) and its various releases that tried to
improve performance... Have you given it up completely?
>
> basically .. does you know Microsoft Powershell ?
>
> to say it in easy words ... this does the same as MS PowerShell...
> but I think "a little bit smarter"
>
> The basic idea was to replace the good old shell PIPE based on STRINGS
> with something better.
>
> If you download and build the distribution you get in the "acmds"
> directory a set of executables. These executable can be used to play
> with:
>
> example:
>
> cat /etc/passwd | asplit -d ":" @ asort -2 I @ acut -f 0,2,3 @ \
> ajoin -d ' | ' -0 "%-15s" -1 "%-5i" -2 "%-5i"
>
> and the tests directory is good source for additional example like
> a tcl server: http://libmsgque.sourceforge.net/tcl_server.htm
>
> or just read the tclmsgque web page:
> http://libmsgque.sourceforge.net/tclmsgque.htm
>
>
> mfg
>
> Andreas Otto
To say the truth, I don't know what powershell is, and by reading the
above I couldn't understand what is the advantage of your library. The
only thing that was clear, was the ability to use sockets internally,
which will enable the pipeline to work with executables on various hosts
(is this true?). What is unclear to me, is whether you have defined an
API that enables the easy transfer of information among processes, so as
each process does not need to parse the output of other processes (and
the input/output data is directly available through APIs...)
Best regards,
George
Andreas Otto
I add additional examples at the end of the overview sheet:
http://libmsgque.sourceforge.net/overview.htm
feel free to download, test and play with the examples
mfg
Andreas Otto
Andreas Otto
-> yes
Hi,
this is right ....
look at the tcl example from
http://libmsgque.sourceforge.net/overview.htm
to get a feeling about the amout of work left over to the programmer
and use the debug output of the las example from overview.htm
http://libmsgque.sourceforge.net/debug_output.htm
to get a feeling what libmsgque is doing for you
mfg
Andreas Otto
Uwe Klein
> To say the truth, I don't know what powershell is, and by reading the
> above I couldn't understand what is the advantage of your library.
http://en.wikipedia.org/wiki/Windows_PowerShell
http://www.codeproject.com/useritems/Introduction_to_Monad.asp
uwe
Alexandre Ferrieux
>
> I add additional examples at the end of the overview sheet:
I looked at these additional examples, and they get me no closer to
answering my initial remark and question.
So I'll repeat them, and ask you *again* to answer. And no, "please
have a look at $some_url" doesn't count as an answer.
Remark: Shell pipelines are NOT limited to text I/O.
Question: Why should anybody use libmsgque instead of standard
pipes ?
-Alex
Andreas Otto
Hi,
Because even if you plan to use the traditional shell
pipeline to send binary data every application, using
this data, have to be aware of it, they need some
common interface to this data and some kind of
protocol -> this just does the libmsgque library ..
Q: Why you are using sockets and not the allready
available stdin/stdout pipeline ?
A: The initial release of libmsgque was using the
stdin/stdout but this was not good ... many
application are using stdin/stdout and stderr
to report some information's, error's ...
these data using the same stream as the
'binary' data and creates a lot of problems..
With the current solution both is possible ..
stdin/stdout to the applications are still open
and the sockets are used for communication
mfg
Andreas Otto
Alexandre Ferrieux
> > Question: Why should anybody use libmsgque instead of standard
> > pipes ?
>
> pipeline to send binary data every application, using
> this data, have to be aware of it, they need some
> common interface to this data and some kind of
> protocol -> this just does the libmsgque library ..
In all cases the producer and the consumer must agree on the semantics
of the data exchanged: field order, dimension, byte order...
If (your hypothesis) you want to avoid formatting/parsing, then the
data must be in native form inside both apps (binary for numbers,
unchanged for strings). No room for abstraction.
What about finishing your Tcl compiler instead ;-) ?
-Alex
Andreas Otto
Hi,
The compiler is allread finished .....
but permanent work is needed to keep this code updated
and I don't have this time ...
It would be a good starting point to take this project
over to the tcl-core team.
But every-body of the core-team should be clear that
adding the compiler to the core will extremely expand
the workforce needed to maintain tcl.
it is more like a double !!!!
TCT have to shift workforce away from the normal Tcl
development towards compiler development.
The tcl-core-team need volunteers to:
1. step into this code
2. add the modifications done to the 8.3.4 core to
the latest core (8.4 and 8.5)
3. finally integrate this product into the tcl mainstream
mfg
Andreas Otto
Alexandre Ferrieux
>
> > What about finishing your Tcl compiler instead ;-) ?
>
> development towards compiler development.
Boy, I *was* joking. Are you ?
-Alex
Andreas Otto
I not
davidn...@gmail.com
wrote:
> On May 8, 5:28 pm, Andreas Otto <aotto1...@onlinehome.de> wrote:
>
> > ANNOUNCE: libmsgque2.3-beta1
>
> > 1. an overview about the basic concept:
> > http://libmsgque.sourceforge.net/overview.htm
>
> After reading the overview above, I'm still lost about what problem
> your framework solves.
It looks sort of similar to what Erlang can do very natively, or what
Java stuff like JMS does. It can actually be pretty handy, if done
right, as a way of distributing things across different machines.
Alexandre Ferrieux
wrote:
Yes but I won't buy a gas factory to do what rsh and pipes already do.
-Alex