RFC: A messaging kernel
[1/7] from: maarten:koopmans:surfnet:nl at: 31-Dec-2002 8:58
All,
I am thinking/playing with the concept of a messaging kernel.
What is that?
IMO, a messaging kernel would allow you to send a message to another
kernel, that dispatches it to the appropiate handler on arrival.
So you would do:
send-message some-uri [ some-message ]
The receiving side would have been initialized with:
message-kernel/add-message-type some-type some-handler
message-kernel/run ;enter the evnt loop, basicallyy a wait
The rest is magic ;-)
Now of course there is a lot of features to include:
- different transports (TCP, UDP, HTTP)
- security
- compression
- balancing
- persistent connections
Think of it as the messaging counterpart of Rugby.
Are there any things that you want to see included?
--TPFKAMK
[2/7] from: petr:krenzelok:trz:cz at: 31-Dec-2002 9:30
Maarten Koopmans wrote:
> All,
> I am thinking/playing with the concept of a messaging kernel.
<<quoted lines omitted: 15>>
> Think of it as the messaging counterpart of Rugby.
> Are there any things that you want to see included?
Hello Maarten,
yes, something like that IS needed imo. I just would like to ask - why
don't you try to contact DocKimbel to send you beta of Uniserve?
Uniserve seems to be something like protocol multiplex engine - you have
services installed, which use modules, e.g. httpd service, which can use
CGI or fastCGI etc module. There is more to Uniserve than what I am able
to describe here.
What I currently lack with Uniserve is - client side of things .... I
think that it should turn into P2P solution (and according to Doc, it
hopefully will), as it currently lacks imo unified tracking of client
side stuff also (I mean opened ports on client).
Uniserve can be good competition to Python's Medusa and I think that
later on, RT could decide to license it for SDK, as it can take Rebol
networking one step further ...
So - I would like to see community cooperation upon one as much as
possible universal project, than later on deciding between two systems,
while both of them lacking certain feature here or there ...
-pekr-
[3/7] from: maarten::koopmans::surfnet::nl at: 31-Dec-2002 10:50
> yes, something like that IS needed imo. I just would like to ask - why
> don't you try to contact DocKimbel to send you beta of Uniserve?
> Uniserve seems to be something like protocol multiplex engine - you have
> services installed, which use modules, e.g. httpd service, which can use
> CGI or fastCGI etc module. There is more to Uniserve than what I am able
> to describe here.
>
I know, and Doc is very good, but....
> What I currently lack with Uniserve is - client side of things .... I
> think that it should turn into P2P solution (and according to Doc, it
> hopefully will), as it currently lacks imo unified tracking of client
> side stuff also (I mean opened ports on client).
>
Exactly. So it would fill in only half of the picture, and it is not
released and....
> Uniserve can be good competition to Python's Medusa and I think that
> later on, RT could decide to license it for SDK, as it can take Rebol
> networking one step further ...
... it would be nothing more than a server io engine to me. I already
have a very well tested, widely used engine myself: hipe, the one from
Rugby.
1) Well tested for almost two years, nice installed base via Rugby.
2) I control it and know it inside-out.
The other point is that where Uniserve is a protocol framework that is
exactly what I want to move away from with Rebol. The power of messaging
and dialects can be used as protocols. The messaging engine will help
you with the networking part.
> So - I would like to see community cooperation upon one as much as
> possible universal project, than later on deciding between two systems,
> while both of them lacking certain feature here or there ...
>
And this is a repeating argument from your side. Why Rugby if we get IOS
and RMP (1.5 years ago)? Why not integrate Rugby with Uniserve (last
year). Why....?
So although I will follow Uniserv with great interest once it becomes
publicly available: no, thanks for now.
--TPFKAMK
[4/7] from: petr:krenzelok:trz:cz at: 31-Dec-2002 11:30
Maarten Koopmans wrote:
>> What I currently lack with Uniserve is - client side of things .... I
>> think that it should turn into P2P solution (and according to Doc, it
<<quoted lines omitted: 3>>
> Exactly. So it would fill in only half of the picture, and it is not
> released and....
1st part true, second part - released to betatesters ...
>> Uniserve can be good competition to Python's Medusa and I think that
>> later on, RT could decide to license it for SDK, as it can take Rebol
>> networking one step further ...
>
> ... it would be nothing more than a server io engine to me. I already
> have a very well tested, widely used engine myself: hipe, the one from
> Rugby.
nothing more
? see below ...
> 1) Well tested for almost two years, nice installed base via Rugby.
> 2) I control it and know it inside-out.
those two points I understand, especially for you, as an developer, 2)
makes sense ....
> The other point is that where Uniserve is a protocol framework that is
> exactly what I want to move away from with Rebol. The power of
> messaging and dialects can be used as protocols. The messaging engine
> will help you with the networking part.
well, as for being nothing more than io engine. While you are probably
right, you should bear in mind, that some ppl may be still interested
into using legacy stuff. i have interoperability in mind - ability to
connect to IRC, Jabber networks, ability to run httpd service, test
locally CGI (fastCGI) stuff, which later on can be just moved to
production Apache server without single line change, etc.
Rebol only solution (dialects) running upon some messaging kernel can
keep us isolated, but otoh I know nothing concrete upon what you plan.
And if you tell me, that you have Rugby as a base transport mechanism in
mind, so it is possible to install functions (services) which can
connect to e.g. IRC, I can see it as just reverse way of what Uniserve
will offer.
Anyway - my intention was not to distract anyone from whatever work! Do
what you think is good to be done. It is still better to have two
solutions available, than none .... I just tried to point out, that in
some case, there can be community split, but maybe I am just too much
scared because of my Amiga history. After all, Rebol community seems to
be real community in comparison to what is happening with the so-called
amiga community nowadays ...
>> So - I would like to see community cooperation upon one as much as
>> possible universal project, than later on deciding between two
<<quoted lines omitted: 5>>
> So although I will follow Uniserv with great interest once it becomes
> publicly available: no, thanks for now.
Look, I can't be responsible upon work of others. I was told certain
things at certain times and their non-delivery was not fault on my side.
1) IOS - I still have to wait for what RT will do with their product.
There seem to be total lack of marketing on their part in regards to
IOS. I have several times asked for IOS road-map, but got no clear
answer. I also know, that some ppl offered to take IOS development
further, so we will see what happens. If RT is not all that interested
in further IOS developement, I think they would be better releasing low
level IOS stuff as part of SDK release, of course for some additional
price, or even special kind of license. If nothing really happens, I
would like to see IOS "cloned" - not desktop (it can be done better by
Cyphre or other UI magician), but low level stuff - RMP, whole
synchronisation stuff, etc.
2) it is publicly available to those, who ask to become beta testers ...
Anyway ... the same as Doc did, the same as Robert did, nothing prevents
you from setting up special group on AltME. That way, you will get more
instant and dedicated replies than you can get here on ml. Just outline
your basic ideas in some doc, post a link to it, and let ppl express
their opinion ...
-pekr-
[5/7] from: robert:muench:robertmuench at: 31-Dec-2002 11:39
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] RFC: A messaging kernel
> Think of it as the messaging counterpart of Rugby.
Hi, isn't such a thing already part of Rugby? If it can be stand-alone
this would be very nice :-)).
> Are there any things that you want to see included?
I would suggest to have a look at http://www.jxta.org This is Suns
effort for a P2P protocol. I'm sure you can use some ideas etc.
Especially the firewall transparent routing. Robert
[6/7] from: gchiu:compkarori at: 2-Jan-2003 15:44
Sounds great Maarten. I would like to see file transfer
as part of this, so that you can still message while doing
a file transfer. And support for VOIP :)
Do you have a time frame for your first release?
On Tue, 31 Dec 2002 08:58:07 +0100
Maarten Koopmans <[maarten--koopmans--surfnet--nl]> wrote:
>Now of course there is a lot of features to include:
>- different transports (TCP, UDP, HTTP)
<<quoted lines omitted: 4>>
>Think of it as the messaging counterpart of Rugby.
>Are there any things that you want to see included?
--
Graham Chiu
[7/7] from: maarten:koopmans:surfnet:nl at: 2-Jan-2003 7:22
Hi Graham,
My timeframe would be Q1. I am first fininshing off some work that needs
the messaging kernel (a policy dialect), and then I'll do the messaging
kernel.
File transfer has come to mind. I'll make sure that some sort of
buffered approach can be used.
--Maarten
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted