On 19/01/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > On 1/19/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > On 19/01/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > On 1/19/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > On 1/19/07, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > > > > It is an enabler of content > > > > > transfer, which in some case might be mobile code, but the fact > that any > > > > > particular document type represents code is something that the > client > > > > > determines, not REST. > > > > > > > > Actually, it's something the server (and therefore, message, and > > > > therefore the connector, and therefore REST) declares, e.g. > > > > > > oops, s/connector/data > > > > I'd be a bit worried from a security perspective if it was the server > > that purely determined remote code execution, > > The server just says "this is code", it doesn't ask the client to > execute it, nor would it care if the client did or not, since that's > not part of its responsibilities as a server. I think that's > fundamental to all client/server architectures, including REST.
But surely then this means that "mobile code" in REST is just "special data type", which IIRC is different from the JERI/Jini approach where mobile code is a fundamental part of the architecture. If all "mobile code" consists of is shift data with a marker saying "this is code" then pretty much every data shifting element ever conceived could claim to support mobile code.
