WD-HTTP-NG-architecture-19980710 Comments

Hello folks,

Just a couple of quick comments about the newly released http ng
architecture working draft.
http://www.w3.org/TR/WD-HTTP-NG-architecture/

First a nasty (confusing) typo:
Sec4., just below Figure 2b:
"For instance, the browser tends to have more surrogate classes
for the object types defined in the Web interface,
and the browser tends to have more true classes"
Second instance of word 'browser' should be 'server'.



Next, some more material comments:

Sec3.6 String Types - "The codeset used in representations of the
string is not specified at this level". Justification? (I guess
I should really read the on-wire doc first, maybe this is covered
there.) Clearly, coded representation has to get nailed down
at some point before message transmission. Is there a reason
why not to go with unicode? Well, sure, probably compatibility
issues with machines/languages/OSes that dont' support unicode.
So why not do a stunt similar to what you did with floating
numbers, allowing user defined string types that specify the
width of the character base set (eg 8 or 16, or possibly other)?
(I think you handle floating pt types very elegantly, btw)

Sec 3.13.2 -
All server-returned data is passed back as a single result,
which is a sequence. By this, I assume that you neatly sidestep
the entire CORBA out & inout paramater issue, and accompanying
memory management & holder quagmires? Looks good. I like.

My one concern would be on the sync/async part. Like CORBA,
users get the choice of sync (blocking) messages that can
return values, or async (non blocking) which can't (ie CORBA
oneways). I don't see any support in http-ng for something
like a corba DII deferred-sync, ie send now, don't block, get
results later either via polling or in a callback.
Personally, I'm a huge fan of future-return style programming.
Was this considered at all? If rejected, why? If not considered,
can I try to advocate it to you :-)?

Sec. 3.13.4 & 3.13.5 - 
The provided syntax you offer for a couple of object types
is extremely useful, more than just to illustrate the object
types themeselves (RemoteObjectBase and GCCollectibleObjectBase),
but to see how you intend the constructs you identify
(types, inheritance, etc.) to be used. In effect, this is 
HTTP-NG's IDL here.
Which leads to some questions: 

(a) Where is the regular grammar for this
declarative language defined? (eg reserved words you use INTERFACE,
TYPE, TYPEID, etc.), structure (semicolon delimiters, END delimiter,
etc.)
(b) What is the rationale for introducing this
new syntactical form
as opposed to (just examples!) (a) something more
similar to, or perhaps derived from, CORBA IDL (b) using XML to declare
a set of markup tags for this declarative structure.
(c) What is the expected consequence of creating declarations ?
With IDL, the process is clear: You need an IDL compiler which
understands the syntax of IDL, and produces either stubs/skeletons
and assorted helpers&holders&whatnot, or diagnostic error messages.
Is that the same intent here? If not, what is? If so, "stubs"
"skeletons" are presumably replaced by terminology more appropriate
to your "true object" "surrogate object" lexicon. Maybe
this is clear to you - I feel I'm missing lots of key details
on "how does this all actually work".


All in all, looks very interesting. I've been looking for
a while now for some real information on what http-ng was really
all about, as opposed to just vague statements I've read to date.

Thanks,
Ron
--------

Ron Resnick
DiaLogos Incorporated
http://www.dialogosweb.com

Received on Sunday, 12 July 1998 08:16:34 UTC