Implementation of Filelink in Instantbird

[Atul Jangra]

Hey,
I wanted to discuss the possible route to implement the file link feature in Instantbird.
Currently I've implemented the XMPP file transfer via IBB method. This method can be used to test the fallback mechanism, though IBB itself is a fallback method ;)

I was thinking that first I can implement the file link feature with any one storage server. This part will involve defining the interface for the storage-providers. This would be helpful in using multiple storage providers. Much of this is already done by Mike Conley, so this shouldn't take much time. We would need to tweak this for IB.
(I don't know what it means when we say we can /use/ mconley's implementation, thus I need some clarification on how this is going to be done)

We can then, test this alone, i.e. without considering it as a fallback for normal ft.

Next can implement the fallback mechanism which will choose which method for ft should be used.

I just what to discuss how should I proceed I Filelink implementation as this is quite important. I would love to hear your views about the implementation plan, and amend it according to what is best for the project.


Regards

[Patrick Cloke]

On 7/12/2013 4:36 PM, Atul Jangra wrote:
> Hey,
> I wanted to discuss the possible route to implement the file link feature in Instantbird.
> Currently I've implemented the XMPP file transfer via IBB method. This method can be used to test the fallback mechanism, though IBB itself is a fallback method ;)

Yes, but it's good to test with, so thanks for implementing it!

> I was thinking that first I can implement the file link feature with any one storage server.

I've seen you say similar things a few times. I don't understand this at
all, the whole point of FileLink is that YOUR code shouldn't care about
what storage service is being used AT ALL. I'm sure you'll test with
only one, but that's OK.

> This part will involve defining the interface for the storage-providers. This would be helpful in using multiple storage providers. Much of this is already done by Mike Conley, so this shouldn't take much time.

No, this has ALL been done already; see [1] and [2].

> We would need to tweak this for IB.

No, we don't. All we need to do is come up with new UI.

> (I don't know what it means when we say we can /use/ mconley's implementation, thus I need some clarification on how this is going to be done)

You should be able to use ALL of his code.

> We can then, test this alone, i.e. without considering it as a fallback for normal ft.

That seems a reasonable first step.

> Next can implement the fallback mechanism which will choose which method for ft should be used.

Do you have any ideas of how this would be done? Where this would be done?

> I just what to discuss how should I proceed I Filelink implementation as this is quite important. I would love to hear your views about the implementation plan, and amend it according to what is best for the project.

What is your current implementation plan? I'd like to hear that before
giving further opinions.

Thanks,
Patrick

[1]
http://mxr.mozilla.org/comm-central/source/mail/components/cloudfile/nsIMsgCloudFileProvider.idl
[2] http://mxr.mozilla.org/comm-central/source/mail/components/cloudfile/

[Atul Jangra]

> I've seen you say similar things a few times. I don't understand this at
>
> all, the whole point of FileLink is that YOUR code shouldn't care about
>
> what storage service is being used AT ALL. I'm sure you'll test with
>
> only one, but that's OK.

I was referring for the testing phase. :)

> Do you have any ideas of how this would be done? Where this would be done?

This needs to be done in the backend. Whenever a ft method fails, we can have initiate the FileLink mechanism. This will involve installing observers on the current status of the file transfer. This is just an idea, I'm sure you guys will come up with something clever.

> What is your current implementation plan? I'd like to hear that before
>
> giving further opinions.

Since all the Filelink implementation is complete, I would first make it work on TB without any backend mechanism. This would involve copying the cloudfile/ to chat/. Implementation is already done, so main work would be somehow linking our ft with it. This part would thus be transferring file with filelink in IB. This will involve the UI changes.
After this we can work on the fallback mechanism.
This is just an idea, I'm sure you guys will have some good plan on this. I would love to hear your views, and start working on this asap, as I am quite behind in my progress.

Regards
Atul

[Atul jangra]

Some more insights:

- When do we call the filelink "Fallback"?
The file transfer is initiated by calling libpurple method |sendFile|.
After that we try to send the file with IBB method(speaking specifically to
our implementation). And if that fails then we try to fallback method:
Filelink.
What I've thought of the this fallback mechanism is as follows:
We will be having a status of a file transfer. And we will have
observers listening to these status. Thus whenever the status of a file
transfer changes, the prpl will be notified and we can act
accordingly(similar to how I'm handling the ui changes in the current
patch) Thus we will get notified of the change in the status of the file
transfer. Now following can be the scenarios where we would want to try
Filelink
- User doesn't want the file through IBB. This is known when the reply
to initiate ibb session receives an error. Then we would want to send the
file through the FileLink. This point is subjective.
- FileSize is too big to be"practically" transferred through IBB.
This is known in the starting of the file transfer. Thus this can be
handled pretty easily.
- The transfer is stopped abruptly. This is the case when the ibb
file transfer was initiated, and some data stanzas were transmitted, but
transfer is on hold right now. This will be known when we are
waiting for a
response to a stanza but we haven't received it for a long time. We cans
set a timeout limit. This timeout will be fixed as we are sending 4096
bytes each time, so timeout can be 1-2 minutes?

In all these cases we need to use Filelink and stop the ongoing ibb
transfer. This can be handled with notifications as I mentioned.
- Where/How will the fileLink method be called.
There are few options to exactly where this method would be called.
1. In sendFile method. But for this we'll require some changes in the
notification method which I proposed above.
2. In the libpurple where we are getting notification about the
status of File
3. We can have a function in prplIFileTransfer which will be called
when we a corresponding notification is arrived.
Again this is very much depend on how we are going to implement the
notification of status changes.
- How does prpl tell the backend that transfer has failed and we need to
start fileLink
This can be done by sending status changes to prpl about the current
file transfer and then prpl will decide if it's a case in which we want to
start the filelink, and if yes, it will call a proper method(maybe defined
in prplIFileTransfer) to do so.
- How can we integrate the fileLink into ib.
Most of the coding is done. We'll be changing the ui to suit IB and this
will require some major changes to suit our UI. But I guess UI can be
tackled later, after we have a working filelink and fallback mechanism.
- Do we want to try the fileLink if the person rejected the file
transfer?
I would like this to be user adjustable. This will depend on many
parameters, mainly user's bandwidth. Would it be feasible to upload a 500MB
iso to a receiver who rejected the file transfer request?

There are some things which I thought of. Presently I'm working on creating
an actual flow of things, how I expect the function callback. I will send
another mail regarding that.

I would like to hear your views on this.

Thanks

> _______________________________________________
> dev-chat mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-chat
>



--
Atul Jangra
Computer Science and Engineering
Indian Institute of Technology ,Delhi

[Florian Quèze]

On Sat, Jul 13, 2013 at 7:49 PM, Atul jangra <atulja...@gmail.com> wrote:
> Some more insights:

The content of this email makes very little sense to me.
Here are some of the reasons why:
- Some "facts" are just plain wrong. Libpurple is a library in C; it
has no "method".
- Some things are overly specific, to the point of being off-topic.
Eg. "IBB"; it's irrelevant when discussing usage of FileLink.
- The poor grammar makes this painful to read. Maybe read the message
again just before sending to fix typos/missing words?
- Plenty of redundancy, eg. "sending status changes to prpl" is
mentioned 3 times (but I still don't know what that means in this
context exactly).

Florian

--
Florian Quèze
Instantbird lead developer

[Atul Jangra]

Thanks for the insights :-)

[Florian Quèze]

On Sat, Jul 13, 2013 at 7:49 PM, Atul jangra <atulja...@gmail.com> wrote:
> Some more insights:

Here are some thoughts about how I think the integration of file
transfer and FileLink in Instantbird should eventually work:
1. The UI needs to inform the chat/ back-end of the file the user wants to send.
2. The prpl should try to handle the transfer, and report either
success or failure (with a reason: can't support this file, ft not
implemented, contact refused, direct connection impossible, ...) to
chat/.
3. When the chat/ code is done trying (not sure if we want to try on
several buddies, or just the current one), inform the UI.
4. In case of failure, the UI can show a notification bar offering to
send through filelink or to configure filelink (if not configured
yet).

For now, and for the sake of moving forward, I'm going to suggest that
for the next week or so you make the UI assume that you are always in
the situation of "4.", and directly start with a notification bar
offering FileLink instead of exchanging anything with chat/ code.

[alet...@fastmail.fm]

> - Some "facts" are just plain wrong. Libpurple is a library in C; it
> has no "method".

Just in case, to clarify:
prpl has nothing to do with "purple", it stands for "protocol plugin".
libpurple is a C library of prpls, inherited from/shared with Pidgin.

> - Some things are overly specific, to the point of being off-topic.
> Eg. "IBB"; it's irrelevant when discussing usage of FileLink.

To be fair, Atul does say "send the file with IBB method(speaking
specifically to our implementation)", which I take to mean that IBB is
the /chat file transfer method that he will "fall back" from at present
when testing, since it's the only one implemented at the moment.

--
http://www.fastmail.fm - Same, same, but different...