[Telepathy] Spec for file-transfer and tubes

[Mads Chr. Olesen]

Just answering a couple of the issues, before I'm off to bed to think
about the remaining issues some more ;-)

On fre, 2007-03-09 at 17:40 +0000, Dafydd Harries wrote:
> Ar 07/03/2007 am 23:19, ysgrifennodd Mads Chr. Olesen:
> > Hi all!
> > 
> > Following the discussion at #telepathy this evening, I have updated
> > smcv's spec proposal a little, to more or less follow the thoughts in
> > the wiki at http://telepathy.freedesktop.org/wiki/Tubes .
> > 
> > My darcs branch is at http://www.cs.aau.dk/~mchro/telepathy-spec.tubes/
> 
> Wow, thanks for drawing this up.
> 
> I've put it into Merge Monkey for easy review:
> 
> http://projects.collabora.co.uk/~monkey/telepathy-spec.tubes/
> 
> Initial thoughts:
> 
>  - StatusChanged says that the new state can be one of
>    LocalPending/RemotePending/Open. In practice, the tube will always begin
>    its life in either LocalPending/RemotePending, and will either get approved
>    or rejected, so in practice you'll only see StatusChanged(Open).
> 
>    The events we really need to represent are Accepted, Rejected, Opened and
>    Closed.
That is correct. So is 4 signals the way to go?

>  - The scheme for approving IP connections using the bus is cunning, but I'm
>    not sure if it's practical. If you're pointing your VNC client at a TCP
>    socket provided by the connection manager, how do you know which port it's
>    going to connect from?
The main problem is that we cannot dictate a certain behaviour, as we
might have these "wrappers" around e.g. VNC. In the VNC-wrapper case I
think security will be something like:
1. Wrapper sets up tube.
2. Wrapper spawns vncviewer localhost:12345 (gets pid of spawned
process)
3. Wrapper gets IncomingINETConnection signal
4. Wrapper does the equivalent of "netstat -tp", to verify that
vncviewer is responsible for the connection (this can be done by looking
in /proc, as mentioned in the draft)
5. Wrapper calls accept/reject.

> Discussing this in the office, we've realised we're not really clear about how
> multi-user tubes should work. The OLPC folk have told us they'd like to have
> it, but we don't really understand how it would be used, so we'll discuss it
> with them and see what falls out.
Hmm, well multi-user as in one-to-many-multicast tubes is a bit cracky.
It could go in the spec, and e.g. Gabble could handle it by opening a
connection to each user - but how to handle the incoming data, which
needs to be prefixed somehow. I would say many one-to-one tubes has much
better defined semantics.

-- 
Mads Chr. Olesen <shiyee at shiyee.dk>
shiyee.dk