Re: 2 APIs and the charter

>
>
>   I don’t see that we really have a way from the charter to be able to
> sort user stories into ones that would fit the « social API » and ones that
> would fit « the federated api ».  Apart from the inconsistencies in the
> charter it seems that the second API is more of an optimisation API which
> should not be visible from the user stories.
>
>
   I would agree that it is not really possible to split user stories up
based on solely API since any user story that involves more than one server
would almost certainly involve both the social API and the federated API.


> Also we need to find a way to use "client/server" in a way that does not
> clash with most internet engineering tradition. What is needed is a word
> for machines that are always on, and machines that are close to the human
> actor, and that may easily be off for a while. Then we will find that all
> our APIs ( if more than one is needed ) are client/server, but that some
> APIs are for machines that are always on.
>

   I would stay away from "always on" for any description as there has to
be an assumption that servers or connections may fail, have scheduled
downtime, etc.  I see it more as a question of systems that only start
connections "clients" and systems that can start or receive connections
"servers".  Perhaps a better way of describing it is systems that are
publicly addressable by some URL.  While I could give my personal computer
a web address, no "server" would know that address.   I use "systems" as
this could be a cloud service, multiple machines on different networks
(internal/external machines for enterprise situations), etc.

Ben