------=_NextPart_000_01BBEDB8.1252C400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
> Over the weekend Rohit (who was in LA and didn't even bother calling me,
> not that I would have had time to see him anyway, but still I'm really
> affected) asked me what ACAP was.
But... but... I was only in LA for 30 hours! But... I was only in LA to
schmooze my way back to Tech! But... oh, well, ya got me. I *didn't rent a
car*. Yes, I with my schmucklike avehicular host Rifkin was reduced to
walking under the influence. Otherwise, I'd definitely swing down... just
to burn up the tank o'gas with the rental! :-)
For added mockery value, I will be in LA Friday night, only, for the
premiere of Beavis and Butthead Do America. More details to come...
> It turns out that ACAP has many meanings:
> o Ames Commute Alternative Program (as in NASA Ames)
My uncle the Cornell prof is working there now. He's tickled pink that they
gave him the honorary title of Colonel, just to get him base housing :-)
> o Army Career and Alumni Program
>
> But even though I know Rohit really does want to join the US Army as his
> first step towards total world domination, somehow
Yes, yes! World Domination RULEZ!
> I think he was
> interested in:
>
> ACAP -- The Application Configuration Access Protocol
Yes indeed. And thanks to the recent interruption in FoRK service due to
net renumbering (HTTP service is still flakey), I wasn't able to recall my
launch order. Here were some of my comments. Basically they are inventing a
new transport protocol for no decent reason. They also significantly
misunderstand the potential of 1.1. HTTP:
===========
Boy, I have real problems with ACAP's "attitude". This is baloney:
http://andrew2.andrew.cmu.edu/cyrus/acap/acap-vs-others.html
<PRE>
PROTOCOL/APPROACH
+------------------------------------------------------+
|ACAP |LDAP, | DHCP | SNMP | HTTP | DNS
|NFS,AFS|Data-|
FEATURE | |et al | | | | | et al
|bases|
+------------------------------------------------------+
Disconnected use | Yes | No | No | No | No | No*1 | No*2 |
No*3|
+------------------------------------------------------+
Client-writable | Yes | Yes | No | Yes*4| No | No | Yes |
Yes |
+------------------------------------------------------+
Potentially Large | Yes | Yes | No | ? | No | No | Yes |
Yes |
+------------------------------------------------------+
Access Control List| Yes | Yes | No | Yes | No | No | Yes | No
|
+------------------------------------------------------+
User Storage | Yes | No | No | No | ? | No | Yes | No
|
+------------------------------------------------------+
Client-Definable | Yes | No | No | No | ? | Yes*5| Yes |
Yes |
+------------------------------------------------------+
Per-user Security | Yes | Yes | ? | No | ? | No | Yes |
Yes |
+------------------------------------------------------+
Server-searching | Yes | Yes | No | ? | No | No | No*6 |
Yes |
+------------------------------------------------------+
client/server | Yes | Yes | Yes | Yes | Yes | Yes | No | No
|
+------------------------------------------------------+
non-proprietary | Yes | Yes | Yes | Yes | Yes | Yes | No | No
|
+------------------------------------------------------+
Yes = has this characteristic
No = does not have this characteristic
? = not fully implemented or unclear if this could support this feature
* = qualified yes or no, see footnote
</PRE>
===========
This is the "attitude" we're up against. And we should fight against this
FUD, IMHO, as "W3C":
HTTP
HTTP is largely structured for document access -- storage and
transport with semantics ("hypertext"). Its main application --
albeit as successful an application as you could imagine -- is a
specific form of document delivery, oriented to presentation of data
M. Wall [Page 7]
Internet DRAFT ACAP VS. OTHER PROTOCOLS September 11, 1996
to users rather than interpreted use by client programs. It is
presently underspecified for uses outside of HTML. While much work
is being done at present to extend and solidify http, its fatal flaw
in this context is a complete lack of data strucutre. Information is
not intended to be machine-parseable; it's not structured, as ACAP
is, for structured subsets of collections of data.
------=_NextPart_000_01BBEDB8.1252C400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> Over the weekend Rohit (who was in =
LA and didn't even bother calling me,
> not that I would have had =
time to see him anyway, but still I'm really
> affected) asked me =
what ACAP was.
But... but... I was only in LA for 30 hours! =
But... I was only in LA to schmooze my way back to Tech! But... oh, =
well, ya got me. I *didn't rent a car*. Yes, I with my schmucklike =
avehicular host Rifkin was reduced to walking under the influence. =
Otherwise, I'd definitely swing down... just to burn up the tank o'gas =
with the rental! :-)
For added mockery value, I will be in LA =
Friday night, only, for the premiere of Beavis and Butthead Do America. =
More details to come...
> It turns out that ACAP has many =
meanings:
> o Ames Commute Alternative Program (as in NASA =
Ames)
My uncle the Cornell prof is working there now. He's =
tickled pink that they gave him the honorary title of Colonel, just to =
get him base housing :-)
> o Army Career and Alumni =
Program
>
> But even though I know Rohit really does want =
to join the US Army as his
> first step towards total world =
domination, somehow
Yes, yes! World Domination =
RULEZ!
> I think he was
> interested in:
> =
> ACAP -- The Application Configuration Access =
Protocol
Yes indeed. And thanks to the recent interruption in =
FoRK service due to net renumbering (HTTP service is still flakey), I =
wasn't able to recall my launch order. Here were some of my comments. =
Basically they are inventing a new transport protocol for no decent =
reason. They also significantly misunderstand the potential of 1.1. =
HTTP:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Boy, I have real =
problems with ACAP's "attitude". This is baloney:
http://andrew2.andrew.cmu.edu/cyrus/acap/acap-vs-oth=
ers.html
<PRE>
=
&=
nbsp; &n=
bsp; &nb=
sp; PROTOCOL/APPROACH
=
&=
nbsp; +-------------------=
-----------------------------------+
=
&=
nbsp; |ACAP |LDAP, | DHCP =
| SNMP | HTTP | DNS |NFS,AFS|Data-|
=
FEATURE =
| |et al | =
| | =
| | et al =
|bases|
=
&=
nbsp; +-------------------=
-----------------------------------+
Disconnected use =
| Yes | No | No | No | =
No | No*1 | No*2 | No*3|
=
&=
nbsp; +-------------------=
-----------------------------------+
Client-writable =
| Yes | Yes | No | Yes*4| No =
| No | Yes | Yes |
=
&=
nbsp; +-------------------=
-----------------------------------+
Potentially Large =
| Yes | Yes | No | ? | No =
| No | Yes | Yes |
=
&=
nbsp; +-------------------=
-----------------------------------+
Access Control =
List| Yes | Yes | No | Yes | No | No =
| Yes | No |
=
&=
nbsp; +-------------------=
-----------------------------------+
User Storage =
| Yes | No | No =
| No | ? | No | =
Yes | No |
=
&=
nbsp; +-------------------=
-----------------------------------+
Client-Definable =
| Yes | No | No | No | ? =
| Yes*5| Yes | Yes |
=
&=
nbsp; +-------------------=
-----------------------------------+
Per-user =
Security | Yes | Yes | ? | No =
| ? | No | Yes | =
Yes |
=
&=
nbsp; +-------------------=
-----------------------------------+
Server-searching =
| Yes | Yes | No | ? | =
No | No | No*6 | Yes |
=
&=
nbsp; +-------------------=
-----------------------------------+
client/server =
| Yes | Yes | Yes | Yes =
| Yes | Yes | No | No |
=
&=
nbsp; +-------------------=
-----------------------------------+
non-proprietary =
| Yes | Yes | Yes | Yes | Yes =
| Yes | No | No |
=
&=
nbsp; +-------------------=
-----------------------------------+
Yes =3D has =
this characteristic
No =3D does not have this =
characteristic
? =3D not fully implemented or unclear if =
this could support this feature
* =3D qualified yes or =
no, see footnote
</PRE>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
br>
This is the "attitude" we're up against. And we should =
fight against this
FUD, IMHO, as "W3C":
=
HTTP
HTTP is largely structured for =
document access -- storage and
transport with semantics =
("hypertext"). Its main application --
albeit =
as successful an application as you could imagine -- is a
=
specific form of document delivery, oriented to presentation =
of data
M. Wall =
&=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p; [Page 7]
Internet =
DRAFT ACAP VS. =
OTHER PROTOCOLS September 11, =
1996
to users rather than interpreted use by =
client programs. It is
presently underspecified for uses =
outside of HTML. While much work
is being done at =
present to extend and solidify http, its fatal flaw
in =
this context is a complete lack of data strucutre. Information is
=
not intended to be machine-parseable; it's not structured, =
as ACAP
is, for structured subsets of collections of =
data.