You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 1999/11/07 07:52:59 UTC
fyi: Cosm Project
I met Adam L. Beberg at the MIT's TR100 event and he mentioned that
they were working on a portability layer for the Cosm project (software
that grew out of his work at distributed.net). The code license isn't
suitable for Apache at the current time, but some people here might
be interested in his work. Below is his comments on APR after I mentioned
where to look for our 2.0 stuff.
....Roy
------- Forwarded Message
Date: Fri, 5 Nov 1999 18:18:26 -0600 (CST)
From: "Adam L. Beberg" <be...@mithral.com>
To: fielding@ics.uci.edu
Subject: Cosm CPU/OS vs. Apache ARP (from TR100)
Message-ID: <Pi...@watcher.mithral.com>
Greetings...
I checked out the Apache 2.0 code and looked through the ARP and compared it
to the Cosm cpu/.os layer (http://cosm.mithral.com/doc/)
The goals are a bit different, which leads to a different structure:
* APR aims to provide some common functions if and only if raw speed is
unaffected, whereas Cosm's goal is to provide a universal API on anything
with a 32bit CPU, #ifdef'ing inside the functions where needed.
* The Cosm API aims to be extremely simple from a enduser view with a low
learning curve. APR is aimed at apache programmers, and so the interface is
a bit more complicated (contexts and things). Also, Cosm is pure ANSI C,
whereas APR is c++ish
* APR is geared very closely to the things Apache needs. Cosm aims to
provide everything a kernel would provide, allowing functions to fail e.g.
if an OS doesn't have threads, thread cration fails, and you do the
non-thread method. Apache will do this decision making on a higher
level.
Neither of these approches is better/worse then the other, they both meet
their goals quite well. I dont know how useful the Cosm libraries would be
to the Apache project, while the #ifdef's allow for optimized code, it's not
an absolute goal, portability is, but performance is extremely critical in
Apache.
Good luck on the Thesis, get back to work ;)
- Adam L. Beberg
The Cosm Project - http://cosm.mithral.com/
beberg@mithral.com - http://www.iit.edu/~beberg/
------- End of Forwarded Message
Re: using ACE for the APR layer WAS Re: fyi: Cosm Project
Posted by Harrie Hazewinkel <ha...@jrc.it>.
Hi,
Some time ago I tried to do something with ACE and IMHO
it is not easy in use. Depending on platform (various
versions of Solaris) it gave lots of weird results.
On a certain time I needed more then 1.5 GB to compile it.
IMHO, used in Apache will create only problems....
Harrie
0- Harrie Hazewinkel --------------------------------------0
mailto:harrie.hazewinkel@jrc.it phone:+39+0332786322
http://operations.ceo.org/~harrie/ fax:+39+0332785641
postal: JRC of the E.C. - - Ispra 21020 (VA) Italy
0----------------------------------------------------------0
60 days until end of contract
Re: using ACE for the APR layer WAS Re: fyi: Cosm Project
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On Mon, 8 Nov 1999, Ian wrote:
> At 01:17 PM 11/08/1999 -0500, Ryan Bloom wrote:
> >
> >Yes, I looked at ACE not long after returning from Linux Expo much earlier
> >this year. It was the one in March I think. ACE has some nice features,
> >but it doesn't fit what we want.
> >
> >ACE is completely written in C++, which has stirred up more than one
> >discussion on this list.
>
> true.. so it kinda rules it out then does it?
Rules it out? No, but it does make it much less likely. I haven't had a
chance to look at the C interfaces for ACE, so I don't know how they are
implemented.
> ACE doesn't have CORBA, there is a product called 'TAO' which uses 'ACE'
> which is the
> CORBA orb.
Ok, I looked at their diagrams and docs, and it looked like some CORBA
stuff was in there. As I said, I looked at ACE much earlier this year,
and I have forgotten a lot about why I didn't like it.
> instead of downloading it, you may want to pose the Question on the ACE
> newsgroup, with your
> concerns.
> of course, if there is a Zero chance for C++, then it is a moot point.
If people would like me to follow up with the ACE list I will, but ACE is
a C++ library, so we need to take that into account before spending time
on it. The opinion in the past has always been to avoid C++ for Apache.
Do we want to use a low-level library that is written in C++ now?
My own opinion is that C++ causes more problems than it solves in
situations like this, and it should be avoided for portability libraries.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: using ACE for the APR layer WAS Re: fyi: Cosm Project
Posted by Ian <ap...@holsman.net>.
At 01:17 PM 11/08/1999 -0500, Ryan Bloom wrote:
>
>Yes, I looked at ACE not long after returning from Linux Expo much earlier
>this year. It was the one in March I think. ACE has some nice features,
>but it doesn't fit what we want.
>
>ACE is completely written in C++, which has stirred up more than one
>discussion on this list.
true.. so it kinda rules it out then does it?
> It is also MUCH more than Apache needs, for
>example all the CORBA stuff. And it doesn't have everything we need, for
>example the ability to call native API's.
>
ACE doesn't have CORBA, there is a product called 'TAO' which uses 'ACE'
which is the
CORBA orb.
as far The native APIs goes, they do the same thing APR is going to do,
they wrap them up
with and depending on the OS you compile against it will use the
corresponding ones.
they also have ACE::OS which has some OS specific things in it. (I
think..its been a while)
>The biggest strike against it was the C++. It has been almost a year
>since I really looked at ACE though, so I can't remember the exact reason
>for not using it instead of creating APR. If you really want me to, I
>could download a newer version, and look at it again.
>
>Ryan
instead of downloading it, you may want to pose the Question on the ACE
newsgroup, with your
concerns.
of course, if there is a Zero chance for C++, then it is a moot point.
..Ian
>
>On Mon, 8 Nov 1999, Ian wrote:
>
>> At 10:02 AM 11/08/1999 -0500, Ryan Bloom wrote:
>> >
>> Since people are looking at APR, and generalizing the API to which you talk
>> to different
>> OS's. has anyone had a look The ADAPTIVE Communication Environment (ACE)
>> (http://siesta.cs.wustl.edu/~schmidt/ACE.html) to achieve this?
>>
>> >From what I see:
>> a) it runs on multiple platforms already NT, OS/390, linux, some Real Time
>> Os's
>> and of course unix
>> b) The licence seems to be right (not LGPL, GPL)
>> "In particular, you can use ACE and TAO in proprietary software and are
>> under no obligation to
>> redistribute any of your source code that is built using ACE and TAO.
>> Note, however, that you
>> may not do anything to the ACE and TAO code, such as copyrighting it
>> yourself or claiming
>> authorship of the ACE and TAO code, that will prevent ACE and TAO from
>> being distributed
>> freely using an open source development model. "
>> c) It is FAST. They use this as a basis for a realtime CORBA ORB.
>> d) It has a very active developer base already.
>>
>>
>> >Adam contacted me directly, and I have replied to his concerns about APR
>> >privately. When he and I come to a conclusion about what APR is and what
>> >Cosm is and where they intersect, I will post a response to Cosm.
>> >
>> >My basic feeling after looking through the code briefly is that Cosm is
>> >not designed for use as portability layer where performance is important,
>> >or where large groups of non-core members are going to use it (i.e. module
>> >writers). That is after only an hour of reading through small pieces of
>> >the code, and I may be wrong, so I want to get Adam's response to my
>> >concerns before I go into more detail here.
>> >
>> >Ryan
>> >
>> >On Sat, 6 Nov 1999, Roy T. Fielding wrote:
>> >
>> >> I met Adam L. Beberg at the MIT's TR100 event and he mentioned that
>> >> they were working on a portability layer for the Cosm project (software
>> >> that grew out of his work at distributed.net). The code license isn't
>> >> suitable for Apache at the current time, but some people here might
>> >> be interested in his work. Below is his comments on APR after I
mentioned
>> >> where to look for our 2.0 stuff.
>> >>
>> >> ....Roy
>> >
>> >
>>
>
>_______________________________________________________________________
>Ryan Bloom rbb@raleigh.ibm.com
>4205 S Miami Blvd
>RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
>
>
Re: UDP support?
Posted by "Kevin A. Burton" <bu...@relativity.yi.org>.
???
This isn't defined in the RFC so I would probably say no.
Why don't you just write your own UDP server?
David Williams wrote:
>
> Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
> transport layer. Or support anything other than TCP?
>
> thanks,
> -david
Re: UDP support?
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> On Wed, 10 Nov 1999, Dean Gaudet wrote:
>
> > i'm not sure what more i can say except that udp sockets aren't connected.
> >
> > try it.
>
> I DID it two years ago. It was my senior project when I graduated from
> college. I KNOW it can be done, because I have done it.
You can probably get away with it if the request fits in a single UDP
packet. The response can take as many as it wants, coz there's only one
client. Forget keepalive.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: UDP support?
Posted by David Williams <dw...@cisco.com>.
Both views are correct. One may open a connected udp socket which
allows a process to communicate with exactly one peer. (The
application may chose the udp port number, or allow the kernel to
chose an ephermal one.)
There are also situations where a server needs to open a well-known
port and listen for requests from multiple clients. In this scenerio
the server may want to have a single process open the socket once.
So that retransmitted requests or multiple PDUs of a single
transaction all get handled by the same process, instead of randomly
be received by different processes.
My comment about the apache process model was related to using
unconnected udp sockets.
thanks,
-david
On Wed, 10 Nov 1999, Ryan Bloom wrote:
> On Wed, 10 Nov 1999, Dean Gaudet wrote:
>
> > i'm not sure what more i can say except that udp sockets aren't connected.
> >
> > try it.
>
> I DID it two years ago. It was my senior project when I graduated from
> college. I KNOW it can be done, because I have done it.
>
> > open up the same udp port in more than one process, and start sending
> > packets. notice how it's random which process get which packets. (unless
> > you broadcast the packets, in which case all the sockets get all the
> > packets).
>
> I think we modified two functions in Apache and two functions in Lynx to
> make it work. If you would like to see it, I am sure I can get the diffs
> from one of the guys I worked with. I lost my copies when I lost my last
> hard drive. :-)
>
> Ryan
>
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
>
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On Wed, 10 Nov 1999, Dean Gaudet wrote:
> i'm not sure what more i can say except that udp sockets aren't connected.
>
> try it.
I DID it two years ago. It was my senior project when I graduated from
college. I KNOW it can be done, because I have done it.
> open up the same udp port in more than one process, and start sending
> packets. notice how it's random which process get which packets. (unless
> you broadcast the packets, in which case all the sockets get all the
> packets).
I think we modified two functions in Apache and two functions in Lynx to
make it work. If you would like to see it, I am sure I can get the diffs
from one of the guys I worked with. I lost my copies when I lost my last
hard drive. :-)
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: UDP support?
Posted by Dean Gaudet <dg...@arctic.org>.
i'm not sure what more i can say except that udp sockets aren't connected.
try it.
open up the same udp port in more than one process, and start sending
packets. notice how it's random which process get which packets. (unless
you broadcast the packets, in which case all the sockets get all the
packets).
Dean
On Wed, 10 Nov 1999, Ryan Bloom wrote:
>
> You're right, it's been a few years, we didn't accept then dup, we
> select'ed and dup'ed. This should make sense now. I knew something was
> wrong when I wrote it, but I couldn't figure out what it was. I still do
> not see why the process model has implications for which type of socket
> are used.
>
> Ryan
>
> On Tue, 9 Nov 1999, Dean Gaudet wrote:
>
> >
> >
> > On Tue, 9 Nov 1999, Ryan Bloom wrote:
> >
> > > I do not understand why the process model has any implications for tcp or
> > > udp sockets.
> >
> > udp sockets aren't connected... so all the packets are delivered to one
> > socket, there's nothing to accept() and dup().
> >
> > Dean
> >
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
You're right, it's been a few years, we didn't accept then dup, we
select'ed and dup'ed. This should make sense now. I knew something was
wrong when I wrote it, but I couldn't figure out what it was. I still do
not see why the process model has implications for which type of socket
are used.
Ryan
On Tue, 9 Nov 1999, Dean Gaudet wrote:
>
>
> On Tue, 9 Nov 1999, Ryan Bloom wrote:
>
> > I do not understand why the process model has any implications for tcp or
> > udp sockets.
>
> udp sockets aren't connected... so all the packets are delivered to one
> socket, there's nothing to accept() and dup().
>
> Dean
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: UDP support?
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 9 Nov 1999, Ryan Bloom wrote:
> I do not understand why the process model has any implications for tcp or
> udp sockets.
udp sockets aren't connected... so all the packets are delivered to one
socket, there's nothing to accept() and dup().
Dean
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
The easiest way to replace tcp with udp in Apache 2.0 will be to just
replace the APR sockets layer with UDP sockets. This should be trivial,
and could be done in a matter of hours. Please take a look at the APR
code in the apache-2.0 repository.
I do not understand why the process model has any implications for tcp or
udp sockets. When I originally made this same modification, we just
accepted the request on the original socket, and dup'ed it immediately.
We then used the dup'ed socket for all of our communication. This is all
possible in APR.
If APR isn't enough, then I would suggest that ANYTHING more that was
needed could be easily accomplished by using a new APR layer in
combination with a UDP-MPM. This would be easy to accomplish.
HTH
Ryan
On Tue, 9 Nov 1999, Ben Laurie wrote:
> David Williams wrote:
> >
> > Ryan, I would be interested in more info. I haven't looked at the
> > APR, and I suppose I need to get a pointer to the new development code
> > base. I understand the need to add reliability to UDP, and I would be
> > doing that for my application. The HTTP/1.1 rfc doesn't require that
> > HTTP be ran over TCP, just that the transport layer be reliable, so I
> > was wondering if someone had successfully implemented an alternative
> > transport layer.
> >
> > I want to leverage the reliability, portability, 3rd party modules,
> > cgi interface, TCP transport, etc. that exists in Apache as a basis to
> > build a new service. But I also want UDP capability.
> >
> > With apache 1.3.9, my concern is that adding UDP support would not be
> > trival because of the process model where a pool of child processes
> > are blocking on a call to accept(), the conn_rec, and lower level I/O
> > routines. All of which presume a process will only communicate with a
> > single client over a single TCP connection. Does 2.0 help any here?
>
> 2.0 is supposed to be more independent of transport and protocol, though
> whether it is independent enough for you depends on what you want!
> Perhaps you should explain more clearly what support you need, or take a
> look and see what you don't get.
>
> I'm interested in pursuing this somewhat.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: UDP support?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
>
> Ryan, I would be interested in more info. I haven't looked at the
> APR, and I suppose I need to get a pointer to the new development code
> base. I understand the need to add reliability to UDP, and I would be
> doing that for my application. The HTTP/1.1 rfc doesn't require that
> HTTP be ran over TCP, just that the transport layer be reliable, so I
> was wondering if someone had successfully implemented an alternative
> transport layer.
>
> I want to leverage the reliability, portability, 3rd party modules,
> cgi interface, TCP transport, etc. that exists in Apache as a basis to
> build a new service. But I also want UDP capability.
>
> With apache 1.3.9, my concern is that adding UDP support would not be
> trival because of the process model where a pool of child processes
> are blocking on a call to accept(), the conn_rec, and lower level I/O
> routines. All of which presume a process will only communicate with a
> single client over a single TCP connection. Does 2.0 help any here?
2.0 is supposed to be more independent of transport and protocol, though
whether it is independent enough for you depends on what you want!
Perhaps you should explain more clearly what support you need, or take a
look and see what you don't get.
I'm interested in pursuing this somewhat.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: UDP support?
Posted by David Williams <dw...@cisco.com>.
Ryan, I would be interested in more info. I haven't looked at the
APR, and I suppose I need to get a pointer to the new development code
base. I understand the need to add reliability to UDP, and I would be
doing that for my application. The HTTP/1.1 rfc doesn't require that
HTTP be ran over TCP, just that the transport layer be reliable, so I
was wondering if someone had successfully implemented an alternative
transport layer.
I want to leverage the reliability, portability, 3rd party modules,
cgi interface, TCP transport, etc. that exists in Apache as a basis to
build a new service. But I also want UDP capability.
With apache 1.3.9, my concern is that adding UDP support would not be
trival because of the process model where a pool of child processes
are blocking on a call to accept(), the conn_rec, and lower level I/O
routines. All of which presume a process will only communicate with a
single client over a single TCP connection. Does 2.0 help any here?
thanks,
-david
On Mon, 8 Nov 1999, Ryan Bloom wrote:
>
> I happen to have done some work on getting Apache to use UDP, and I can
> tell you it isn't worth it. I did the work a few years ago, and what we
> found was that you basically have to re-create TCP to get the kind of
> reliability that is required for a web server.
>
> Having said that, APR could be used to abstract out the transport layer.
>
> If you want more info, let me know.
>
> Ryan
On Tue, 9 Nov 1999, Kevin A. Burton wrote:
> ???
>
> This isn't defined in the RFC so I would probably say no.
>
> Why don't you just write your own UDP server?
>
>
> On Mon, 8 Nov 1999, David Williams wrote:
>
> > Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
> > transport layer. Or support anything other than TCP?
> >
> > thanks,
> > -david
> >
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
>
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I happen to have done some work on getting Apache to use UDP, and I can
tell you it isn't worth it. I did the work a few years ago, and what we
found was that you basically have to re-create TCP to get the kind of
reliability that is required for a web server.
Having said that, APR could be used to abstract out the transport layer.
If you want more info, let me know.
Ryan
On Mon, 8 Nov 1999, David Williams wrote:
> Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
> transport layer. Or support anything other than TCP?
>
> thanks,
> -david
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
UDP support?
Posted by David Williams <dw...@cisco.com>.
Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
transport layer. Or support anything other than TCP?
thanks,
-david
Re: using ACE for the APR layer WAS Re: fyi: Cosm Project
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Yes, I looked at ACE not long after returning from Linux Expo much earlier
this year. It was the one in March I think. ACE has some nice features,
but it doesn't fit what we want.
ACE is completely written in C++, which has stirred up more than one
discussion on this list. It is also MUCH more than Apache needs, for
example all the CORBA stuff. And it doesn't have everything we need, for
example the ability to call native API's.
The biggest strike against it was the C++. It has been almost a year
since I really looked at ACE though, so I can't remember the exact reason
for not using it instead of creating APR. If you really want me to, I
could download a newer version, and look at it again.
Ryan
On Mon, 8 Nov 1999, Ian wrote:
> At 10:02 AM 11/08/1999 -0500, Ryan Bloom wrote:
> >
> Since people are looking at APR, and generalizing the API to which you talk
> to different
> OS's. has anyone had a look The ADAPTIVE Communication Environment (ACE)
> (http://siesta.cs.wustl.edu/~schmidt/ACE.html) to achieve this?
>
> >From what I see:
> a) it runs on multiple platforms already NT, OS/390, linux, some Real Time
> Os's
> and of course unix
> b) The licence seems to be right (not LGPL, GPL)
> "In particular, you can use ACE and TAO in proprietary software and are
> under no obligation to
> redistribute any of your source code that is built using ACE and TAO.
> Note, however, that you
> may not do anything to the ACE and TAO code, such as copyrighting it
> yourself or claiming
> authorship of the ACE and TAO code, that will prevent ACE and TAO from
> being distributed
> freely using an open source development model. "
> c) It is FAST. They use this as a basis for a realtime CORBA ORB.
> d) It has a very active developer base already.
>
>
> >Adam contacted me directly, and I have replied to his concerns about APR
> >privately. When he and I come to a conclusion about what APR is and what
> >Cosm is and where they intersect, I will post a response to Cosm.
> >
> >My basic feeling after looking through the code briefly is that Cosm is
> >not designed for use as portability layer where performance is important,
> >or where large groups of non-core members are going to use it (i.e. module
> >writers). That is after only an hour of reading through small pieces of
> >the code, and I may be wrong, so I want to get Adam's response to my
> >concerns before I go into more detail here.
> >
> >Ryan
> >
> >On Sat, 6 Nov 1999, Roy T. Fielding wrote:
> >
> >> I met Adam L. Beberg at the MIT's TR100 event and he mentioned that
> >> they were working on a portability layer for the Cosm project (software
> >> that grew out of his work at distributed.net). The code license isn't
> >> suitable for Apache at the current time, but some people here might
> >> be interested in his work. Below is his comments on APR after I mentioned
> >> where to look for our 2.0 stuff.
> >>
> >> ....Roy
> >
> >
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
using ACE for the APR layer WAS Re: fyi: Cosm Project
Posted by Ian <ap...@holsman.net>.
At 10:02 AM 11/08/1999 -0500, Ryan Bloom wrote:
>
Since people are looking at APR, and generalizing the API to which you talk
to different
OS's. has anyone had a look The ADAPTIVE Communication Environment (ACE)
(http://siesta.cs.wustl.edu/~schmidt/ACE.html) to achieve this?
>From what I see:
a) it runs on multiple platforms already NT, OS/390, linux, some Real Time
Os's
and of course unix
b) The licence seems to be right (not LGPL, GPL)
"In particular, you can use ACE and TAO in proprietary software and are
under no obligation to
redistribute any of your source code that is built using ACE and TAO.
Note, however, that you
may not do anything to the ACE and TAO code, such as copyrighting it
yourself or claiming
authorship of the ACE and TAO code, that will prevent ACE and TAO from
being distributed
freely using an open source development model. "
c) It is FAST. They use this as a basis for a realtime CORBA ORB.
d) It has a very active developer base already.
>Adam contacted me directly, and I have replied to his concerns about APR
>privately. When he and I come to a conclusion about what APR is and what
>Cosm is and where they intersect, I will post a response to Cosm.
>
>My basic feeling after looking through the code briefly is that Cosm is
>not designed for use as portability layer where performance is important,
>or where large groups of non-core members are going to use it (i.e. module
>writers). That is after only an hour of reading through small pieces of
>the code, and I may be wrong, so I want to get Adam's response to my
>concerns before I go into more detail here.
>
>Ryan
>
>On Sat, 6 Nov 1999, Roy T. Fielding wrote:
>
>> I met Adam L. Beberg at the MIT's TR100 event and he mentioned that
>> they were working on a portability layer for the Cosm project (software
>> that grew out of his work at distributed.net). The code license isn't
>> suitable for Apache at the current time, but some people here might
>> be interested in his work. Below is his comments on APR after I mentioned
>> where to look for our 2.0 stuff.
>>
>> ....Roy
>
>
Re: fyi: Cosm Project
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Adam contacted me directly, and I have replied to his concerns about APR
privately. When he and I come to a conclusion about what APR is and what
Cosm is and where they intersect, I will post a response to Cosm.
My basic feeling after looking through the code briefly is that Cosm is
not designed for use as portability layer where performance is important,
or where large groups of non-core members are going to use it (i.e. module
writers). That is after only an hour of reading through small pieces of
the code, and I may be wrong, so I want to get Adam's response to my
concerns before I go into more detail here.
Ryan
On Sat, 6 Nov 1999, Roy T. Fielding wrote:
> I met Adam L. Beberg at the MIT's TR100 event and he mentioned that
> they were working on a portability layer for the Cosm project (software
> that grew out of his work at distributed.net). The code license isn't
> suitable for Apache at the current time, but some people here might
> be interested in his work. Below is his comments on APR after I mentioned
> where to look for our 2.0 stuff.
>
> ....Roy