| OOP | Architecture
Where does the web GET/PUT/POST object system fit in, compared with the object models and type systems of Java, SmallTalk, Objective C, Modula-3, python, perl, Tcl, REXX, ILU, Ada9x, scheme, CLOS, ML, C++?
This is a comparison of systems which specify have not just an abstract model, but also runtime (intra- or inter-process) mechanisms. CORBA in general is not such a system, but the CORBA language mappings and IIOP are.
I should add info on the runtimes of python, perl, tcl, scheme48, Modula-3, and smalltalk-80, as well as inter-process mechanisms used with those languages. Aha! Also plan 9 name/file service protocol (union links)
I should learn enough to add SOM/DSOM, dylan, and commonlisp to this table.
The web column is something of a guess
|Issue||COM/DCOM notes||ILU notes||Java/RMI notes||Web|
|Interface Identifiers||IID is a guuid; by convention/spec, changing the interface requires changing the IID||typeid is a hash of the object type (interface), wich can include a brand||administrative hierarchy (ala DNS) of interface names (java.lang., sun., w3c. ...). I haven't seen any conventions regarding lifecycle issues of Java interfaces||things like HTTP/1.0 are interface IDs of a sort, as are RFCNNN. Accept: headers and PEP protocols affect the interface. Some folks have talked about URLs that refer to collections of Accept: headers or PEP protocols.|
|Interface Negotiation||QueryInterface||punt to name service||???||Accept: headers (ala multi-QI?) PEP protocols. interface info in DNS (webX records ala MX records? path: scheme?)|
|Object identifiers (accross address spaces)||Monikers (including URL monikers): binding, asynchronous binding||object ID = server ID@object ID. string binding handle has oid + contact infos. Extensible parsing support for URLs, CORBA IORs||???||URLs|
|interface artifacts (files) and naming (interface repository)||many .idl files to many interfaces. Type library maps IID to compiled representation of interface from .idl file for dynamic dispatch||one .isl file to one "interface" (namespace), which can contain many object types (interfaces) Hmmm... some runtime interface discovery? (type info over the wire?)||one public interface per .java/.class file perhaps use foo.jar#interface when multiple .class files in one .jar file||RFC index :-) We've talked about using a link relationship as an interface discovery mechanism|
|Namespaces and code artifacts (files)||registry maps clsid's to DLL filenames||no direct support for dynamic loading, as far as I can tell||???||URLs point to implementations (format, i.e. instruction set can be negotiated)|
|Code Migration||Custom marshalling||???||object pass-by-value including bytecode implementation||GET migrates (well... snapshots) object state|
|Inheritance of interfaces||Single Inheritance||MI. multiple SUPERTYPES allowed in object types.||SI|
|Imlementation inheritance||classes (implementations) can expose (inherit) multiple interfaces. Aggregation models implementation inheritance. Delegation (TIE) is always an option, of course.||Implementation inheritance is a language-runtime issue||Classes can implement (inherit) multiple interfaces, but can only extend (inherit) one superclass|
|Return values, exceptions||COM methods must (should?) return HRESULT, ala Tcl_Result: an exit status. MIDL has a [retval] attribute||ILU has both first class return values and typed exceptions. Hmmm... how are exceptions identified?||first class return values and exceptions (which are objects).||NNN result code + one-liner + MIME header/body|
|Out Parameters||MIDL [out] attribute. COM uses these a lot, N.B. the RIID/void** combo||ISL OUT keyword||how do these map to java?|
|Root of object hierarchy||IUnknown (QueryInterface, Addref, Release)||
see runtime/kernel/type.c ILUGetTypes ILURegisterGCInterest ILUUnregisterGCInterest ILUPing -is-a /* for CORBA support */
|CORBA object reference operations.||GET/POST?|
|Asynchronous methods||not implemented in DCOM so far, so I hear. I suppose there's a MIDL attribute (or one could be added)||ILU has an ASYNCHRONOUS keyword. Supported inTCP and UDP (hack!) transports.|
|Resource management||AddRef/Release. PING sets (see DCOM internet draft)||COLLECTIBLE keyword (implemented -- at some level -- using reference counting, as I recall)||implicit storage mgmt (weak refs? finalization?)||Referrer: gives clues about in-links. We should work towards mechanisms that make the web "eventually consistent"|
HMMM: GET is kinda like
all in one round-trip.
perhaps format negotation/PEP negotation and QueryInterface relate in some way: model each combination of request headers and return types as a separate method signature. Then consider the GET method as horrendously overloaded. Or another way to look at it: a zillioin different interfaces with subtly different GET methods.
Have a look at burchard's model for starters. (as he says, the IDL needs spec annotations. What was that larch-like thingy I saw for IDL? And I also saw a CORBA/Larch reference... levinson, I think).
Hmmm... URLs that represent DII invoke stuff (aka IDispatch::invoke) from DOMC workshop.
What are the Patterns for the web?
The web is a collection of documents, which have similar structure and intent; concurrent get()s, atomic put()s and delete()s...