4 ms·

I've quickly jotted some thoughts here: http://damnkids.posterous.com/rich-format-unix-pipes http://damnkids.posterous.com/rich-format-unix-pipes Regarding thi

I've quickly jotted some thoughts here: http://damnkids.posterous.com/rich-format-unix-pipes http://damnkids.posterous.com/rich-format-unix-pipes Regarding this version, standardizing on a particular transfer format is a bad idea. If history has shown anything, it's that we like to reinvent this stuff and make it more complicated than necessary (see also XDR, ASN.1, XML, etc. :) pretty much on a 5 year cycle or thereabouts. Do the bare minimum design necessary and let social convention evolve the rest.

alexlarsson 14y ago
Having to many different formats is also a problem though, as incompatible formats means you can't combine two apps in a pipepine. The negotiations in dtools is made using a F_GETLK hack with a magic value offset. That approach could easily be extended to support multiple formats.
- forgotusername 14y ago
  The way I see it there's two distinct problems being coupled together, kinda like inventing HTTP but defining it only to be used with (html, gif, png) or something. The reality is that if your solution gets even some adoption, conventions will quickly emerge based on actual use rather than expected use, which almost never goes well. Additionally when some after-market use is discovered that wasn't part of the original spec, yet makes fabulous sense, existing implementations may be better positioned to deal with it (instead of suddenly finding they're being fed PNG files which are actually base64-encoded XML, or something mad like that, typical shoehorning crap). Similarly, producing a big ecosystem of utilities to go along with it will probably result in a bunch of 1970s style compatibility commands that nobody actually uses any more (say, in 2030). But feel free to bake a glib-specific serialization in and I'll feel free to pass it up. ;) Love your fcntl() hack. My kind of hack!
- deleted 14y ago
  [deleted]

alexlarsson 14y ago

Having to many different formats is also a problem though, as incompatible formats means you can't combine two apps in a pipepine. The negotiations in dtools is made using a F_GETLK hack with a magic value offset. That approach could easily be extended to support multiple formats.

forgotusername 14y ago
The way I see it there's two distinct problems being coupled together, kinda like inventing HTTP but defining it only to be used with (html, gif, png) or something. The reality is that if your solution gets even some adoption, conventions will quickly emerge based on actual use rather than expected use, which almost never goes well. Additionally when some after-market use is discovered that wasn't part of the original spec, yet makes fabulous sense, existing implementations may be better positioned to deal with it (instead of suddenly finding they're being fed PNG files which are actually base64-encoded XML, or something mad like that, typical shoehorning crap). Similarly, producing a big ecosystem of utilities to go along with it will probably result in a bunch of 1970s style compatibility commands that nobody actually uses any more (say, in 2030). But feel free to bake a glib-specific serialization in and I'll feel free to pass it up. ;) Love your fcntl() hack. My kind of hack!
deleted 14y ago
[deleted]