[epistasis]

Defaulting to a data serialization scheme like Avro or Protocol Buffers could be used here, especially with a small amount of shell support to automatically convert terminal-destined data serialization streams to a text string.

It would be an interesting to see if any such projects exist, because it would fit very easily into the current pipe IPC infrastructure, with the addition of transformative pipelines for interfacing with the existing string-base utilities, but that's necessary anyway.

I mean to say that there's no need to modify existing IPC mechanisms, just a need to establish a common serialization standard and embed it into a shell.

[Arnavion]

>Defaulting to a data serialization scheme like Avro or Protocol Buffers could be used here

>I mean to say that there's no need to modify existing ICP mechanisms, just a need to establish a common serialization standard

PS gives you two things though. It doesn't just give you objects, it also gives you the behaviors of those objects as implemented by the runtime (CLR) that is common between both endpoints of the communication.

For example, consider a command that returns a list of processes running on the current session as a List of Process objects. This list is then piped to a command that filters the list to a sublist of processes that have a particular Name property. Finally, this sublist is passed to a third command that calls the Process.Kill() method on each of those objects.

This requires that all three commands not only agree on the structure of a Process object (as protobuf would provide) but also that it has a Kill() method, etc. This is possible in PS because all three commands are running in the same common runtime, but not possible with generic IPC.

IPC of complex objects has existed on Windows even before the CLR with COM and DCOM, and again both of these are more than serialization mechanisms, since they must support cross-process data as well as behavior.

[epistasis]

Interesting, in a unified object programming environment like the CLR I could see that being very useful.

Such live methods could also be implemented in, say, Python by constructing objects from an Avro data stream. Or structs/stubs could be autopopluated in C with the proper library, but that would require the entire POSIX C world to be codified into a standard serialization.

It would be a lot of work, but I think that it still fits inside an Avro-style data serialization scheme, plus proper runtime support. The runtime deserialization is really where the magic happens. And I think the serializaiton, deserialization is necessary to maintain proper process separation, particularly in languages like C.