Always having one Dillo even when you exec dillo is practically the same as always having one Dillo. And as a sort of server mode, in the sense that you just send a message and exit instead of running and doing the stuff. I took a look at your patch, you mainly do the same as I did, but you added much code to handle all the extra commands. I would handle the "server" commands the same as the cmd commands, they are mostly the same anyway. Simpler, more code reuse, smaller and less code. My patch doesn't do that yet, but that's because dillo.c needs to be rearranged a bit to make it possible, wanted a working patch first, and see what people think about it before wasting time finishing it.
I mean, removing the possibility of having another Dillo instance is equivalent restricting its usage. That's why I suggested the other solution.
Concerning the second advantage (not using dpid): performance reasons would be of concern especially when large amount of data need to be passed from and to dillo (https), but maybe we need to quantify this before.
I don't understand your point, performance reasons are of concern only when using dpid, because dpid copies data, so what exactly has this to do with my patch?
Your patch was also meant to get rid of dpid, if I understood correctly. My point was that I don't think dpid is so expensive apart maybe for https: The structure of dpid is not optimal for https: the dpidservice gets data from internet and the it passes it to dillo. It adds a proxy, and that may reduce throughput. But this should be quantified and proved.
Good to know it's possible, and that it depends only on the widget toolset if it's supported or not.
This is in fact a X feature. It just happens that gtk-1.2 did not support it. -- Melvin Hadasht