dbus - comments requested, here's one

[Luke Kenneth Casson Leighton]

On Fri, Jun 25, 2004 at 10:36:16AM +0200, Tako Schotanus wrote:
> Luke Leighton wrote:
> 
> >*exasperated*.  _why didn't you look at freedce?_
> >
> >http://sf.net/projects/freedce
> > 
> >
> I can't speak for the developers of course, because I'm not one of them, 
> but have you considered that they might not have known about this project?
 
  yes.  it's one of the most important strategic projects in existence
  in the fight against microsoft's domination of corporate and home
  computing, and yet no-one in open source knows xxxx-all about it.

> >most disappointed,
> >
> > 
> >
> Aren't you being overly negative? 

 ... i just hate to see 250,000 lines of incredibly well designed
 code go to waste just because the US government has stupidly
 classified it [privately] as a weapon - because that's what they
 use [used] it for.


> Why not try to convince the developers 
> that using freedce would be a big advantage? Just take a look at the 
> DBus code and docs 

 i will.

 i did look up the dbus message and protocol formats.

 that was one of the reasons why i was so dismayed: the features
 and protocol outlined in the documentation are so startlingly
 similar to DCE/RPC's UDP transport layer.


> and with your experience of freedce give your opinion 
> of how easy or difficult it would be to replace the current 
> communication/marshalling code with freedce and what kind of adavantages 
> that would bring.

 the "crux" point will be the IDL compiler (70,000 lines of code,
 50,000 of which is marshalling / unmarshalling code).

 the IDL compiler has been extremely well designed, such that
 new parser engines can be added in.

 so, whatever IDL files already exist, if you _wanted_ to back-support
 the dbus IDL format, you could.

 .... but to be honest it'd probably be a lot quicker to write a
 perl or python script to convert the files to DCE/RPC IDL format!


 one thing that DCE/RPC _doesn't_ support - specifically - is
 special recognition of UTF-8 strings.

 and you _shouldn't have to_: it's just a null-terminated ascii
 string.

 in DCE/RPC you _do_ have a "string" specifier which basically means
 "anything that's zero-terminated, and the thing can be any size".

 in other words, you can have a [string] char* data, you can
 have a [string] unsigned int *data i _think_ you can even have
 a [string] struct random_struct *data and it needs to be
 terminated with enough zeros of sizeof(struct random_struct).

 

> Only pointing out that there is something better that can be used most 
> likely won't be enough because if the current investment the developers 
> have already made into the DBus code, they would probably need a 
> compelling reason (several more likely) to make the switch from familiar 
> to unfamiliar code.
> 
> Currently I can't seem to access the one link to documentation on the 
> freedce website so there isn't much to go by. Any examples you can give 
> of the code, IDL and tool usage?
 
 www.opengroup.org/dce is a good starting point.  as i mentioned
 cc'd to list and to david, there are a couple of coding examples
 with freedce, but if you want more (including a simple file read/write
 client/server app) then you need to look at dce 1.2.2 from the
 opengroup's site - and that's a 120mb download including docs.

 l.