Linked by Hadrien Grasland on Sun 29th May 2011 09:42 UTC
OSNews, Generic OSes It's funny how trying to have a consistent system design makes you constantly jump from one area of the designed OS to another. I initially just tried to implement interrupt handling, and now I'm cleaning up the design of an RPC-based daemon model, which will be used to implement interrupt handlers, along with most other system services. Anyway, now that I get to something I'm personally satisfied with, I wanted to ask everyone who's interested to check that design and tell me if anything in it sounds like a bad idea to them in the short or long run. That's because this is a core part of this OS' design, and I'm really not interested in core design mistakes emerging in a few years if I can fix them now. Many thanks in advance.
Thread beginning with comment 474976
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Comment by Kaj-de-Vos
by xiaokj on Sun 29th May 2011 21:58 UTC in reply to "RE[7]: Comment by Kaj-de-Vos"
xiaokj
Member since:
2005-06-30

Personally, I prefer something lighter too: the HTTP protocol itself is a wonder, and it is much lighter than the tag heavy XML, of course.

However, a specification sheet is a good idea since implementations can, and do, change. Better to code with expectation of change rather than go by "interface memory". If you wanted to have something be as abstract as declarative would allow, then why strap yourself down with black magic? Again, something light would be very nice too. Maybe just a version number is good enough, but still.

Glad that I could actually understand you with just the magic 2 words. It may not be esoteric, but this is proper old school (actually, more like good sense than old).

Reply Parent Score: 2

RE[9]: Comment by Kaj-de-Vos
by Kaj-de-Vos on Sun 29th May 2011 22:11 in reply to "RE[8]: Comment by Kaj-de-Vos"
Kaj-de-Vos Member since:
2010-06-09

The best declarative interface is a self-descriptive one. Which has the effect of the metadata specification being woven into the communication. In that case, there is of course still a standard for what the data can look like, but that standard is fixed, like a type system.

Reply Parent Score: 1

RE[10]: Comment by Kaj-de-Vos
by Alfman on Mon 30th May 2011 05:15 in reply to "RE[9]: Comment by Kaj-de-Vos"
Alfman Member since:
2011-01-28

It's difficult to understand you without a specific reference to what you mean.

I'm going to take a stab at it and guess that SOAP (the successor to xml-rpc) might be the most popular instance of the type of interface you are alluding to?

http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm

In ASP.NET, the soap interface is a derivation of the function prototype, therefore, in this instance SOAP hasn't really extended the expressiveness of the function prototype; but in theory the potential is there.

I'd be really interested in seeing good examples of SOAP which have been exploited beyond wrapping regular functions. Anyone familiar with any?

JSON is another popular interchange format for web browsers, often prefered over xml due to more compactness and better correlation to abstract data types.

http://www.json.org/


Kaj-de-Vos, unless I'm mistaken, it don't seem like you have a problem with RPC itself, but with the non-extensible interfaces provided by a C function prototypes.

If this is the case, then I understand. And now I am forced to admit that C function prototypes are not very future compatible.

C++ supports overloaded functions, so you could get away with adding more parameters in the future, but the model breaks down with too many variants, and in any case it would be C++ specific.

How do you feel about languages which permit/require named parameters? The parameters are effectively a hash table. I think it's a future-friendly model, but I await your comments.

Reply Parent Score: 2