There is no implicit versioning in the actual request protocol. That would have been impossible to maintain in the long run. Instead, there is a "protocol version". We can bump it when there are incompatible changes on any protocol and it invalidates all of them. So a sim version 7 will refuse to connect to a server version 6 and vice versa. This gives us both control and simplicity.
Melanie On 31/03/2014 18:45, Jim Williams wrote: > Seems reasonable to me...A design approach I would have taken. > > One question. Is there some sort of versioning built into the protocol? > One verb yes, but the dictionary numbers the definitions..... > > > On Mon, Mar 31, 2014 at 12:35 PM, Melanie <mela...@t-data.com> wrote: > >> This isn't designed as RPC, it's designed as REST. One URL/VERB >> combination for each function. >> We wanted to get away from the RPC concept. Let's not take backwards >> steps here. >> >> Melanie >> >> On 31/03/2014 15:15, Oren Hurvitz wrote: >> > This isn't overloading: it's an RPC endpoint that accepts many methods. >> You >> > wouldn't create a separate endpoint for each method, would you? >> > >> > >> > >> > >> > -- >> > View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html >> > Sent from the opensim-dev mailing list archive at Nabble.com. >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev@lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev