Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Thursday 28 February 2002 10:56 pm, Mark Baker wrote: > POST it a representation of some food, and it gets fed. > POST it a representation of a hand, and it gets petted. > (logically, of course 8-) This is the point though... to a large degree all that's really happening is decomposition/tunelling of higher-level communication patterns on a lower-level substrate... there are advantages and disadvantages to this. > Yup. But everything that can be done by distributed computing can > be done by distributed hypermedia. It's complete. Sure... and all computation can accomplished using SK combinators. One thing I've often done in developing object interfaces is to essentially make everything a "bag" of properties (get/set/remove), allowing arbitrary extension of "types" at runtime (in JAVA you can do it through a custom classloader if you want). This can be very beneficial (slot-based programming is similar BTW). Anyone who's done this (especially if they're an old lisp hacker ;-)) will eventually question the need for objects/interfaces in the first place... after all, the common substrate is all you need. The answer, as it is for the applicability of anything, is "it depends". Reductionism is fine (big fan of reductionism and minimalism in general), but you also need the higher level of organization, and labels to apply to them. Once you start operating at that level, the underlying components become less relevant... that's the whole point of abstraction. Once you start modelling higher-level applications (working at a higher level of abstraction), will the choice of REST be truly significant? Will the choice of REST using HTTP vs REST using <whatever> be significant?
|
