DropBox Type Of App
-
I am thinking of writing something like DropBox. I'm trying to decide on the right technologies. For the service I will need to upload/download files, and a way to call back to clients with notifications: 1. I tested WCF, but it has been difficult to get working. There's always come config setting that is not right which gives me strange errors. 2. I tested a SignalrR service which was very simple to set up and handles callbacks easily. but from what I can see SignalR doesn't do file upload/download. I thought of converting the file to a byte array, attaching it to a class and sending it to the server, but that doesn't feel right. I need to A) Upload/Download Files B) Call back to the client What's the right service to do with this? Thank you
zephaneas wrote:
B) Call back to the clien
That, as stated, is almost never the correct solution. A server might send a message to a client, but using the same communication link that the client established in the first place.
zephaneas wrote:
which gives me strange errors.
Err...welcome to network traffic? You either roll your own API of find another and use it. And there are many, many choices. As mentioned in the other thread File Transfer Protocol (FTP) is one specifically addressing file transfer. Other protocols tend to be message based and not file based. You might want to start first with a file listing service instead of a transfer service. Thus the client will list the files on the server and nothing else. That is going to be easier and is something you would need to do anyways.
-
I don't think that Dropbox works with callbacks; instead, it might be checking the progress on the document ad-hoc, to update a shell overlay icon when needed.
zephaneas wrote:
What's the right service to do with this?
For A there'd be FTP. For B, any socket would do as long as it can stay connected, and in a not-always-connected environment I'd recommend email (or a similar structure).
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
I don't think that Dropbox works with callbacks
Why do you think that? Any reason in particular?
If it's not broken, fix it until it is
-
zephaneas wrote:
B) Call back to the clien
That, as stated, is almost never the correct solution. A server might send a message to a client, but using the same communication link that the client established in the first place.
zephaneas wrote:
which gives me strange errors.
Err...welcome to network traffic? You either roll your own API of find another and use it. And there are many, many choices. As mentioned in the other thread File Transfer Protocol (FTP) is one specifically addressing file transfer. Other protocols tend to be message based and not file based. You might want to start first with a file listing service instead of a transfer service. Thus the client will list the files on the server and nothing else. That is going to be easier and is something you would need to do anyways.
B) Call back to the clien
jschell wrote:
That, as stated, is almost never the correct solution.
Why not?
If it's not broken, fix it until it is
-
I am thinking of writing something like DropBox. I'm trying to decide on the right technologies. For the service I will need to upload/download files, and a way to call back to clients with notifications: 1. I tested WCF, but it has been difficult to get working. There's always come config setting that is not right which gives me strange errors. 2. I tested a SignalrR service which was very simple to set up and handles callbacks easily. but from what I can see SignalR doesn't do file upload/download. I thought of converting the file to a byte array, attaching it to a class and sending it to the server, but that doesn't feel right. I need to A) Upload/Download Files B) Call back to the client What's the right service to do with this? Thank you
You should reconsider WCF. Yes; once you get the settings right, "save" them. Other than that, we have lots of services communicating with different third parties exchanging multi-megabyte compressed payloads (shipping documents and label images) asynchronously from multiple locations.
-
Eddy Vluggen wrote:
I don't think that Dropbox works with callbacks
Why do you think that? Any reason in particular?
If it's not broken, fix it until it is
Kevin Marois wrote:
Any reason in particular?
Two; having written an overlay icon shell plugin thingy, which requests the status of a file as soon as it needs to show an icon in the explorer, and the second being the Dokan-plugin, which demonstrates how easy it would be create a drive that shows whatever you want (like remote files) as if they are part of the filesystem - also works on the "whenever Explorer shows it and needs it" principle. Not on calling back to the system to let it know that the final bytes have been written. That is already implied by closing the stream :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
B) Call back to the clien
jschell wrote:
That, as stated, is almost never the correct solution.
Why not?
If it's not broken, fix it until it is
Kevin Marois wrote:
Why not?
Because of the nature of the thing; a server serves the clients' request. If the client needs an update, it should ask the server. Having the server notify the client is a well-known anti-pattern.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Kevin Marois wrote:
Why not?
Because of the nature of the thing; a server serves the clients' request. If the client needs an update, it should ask the server. Having the server notify the client is a well-known anti-pattern.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
I'm not sure if I agree with that. From what I can see that's the whole point of WebSockets, and SignalR which is built on it - to maintain a connection to the clients for e purpose of real-time communication.
"Real time"?
zephaneas wrote:
From what I can see that's the whole point of WebSockets
Depends on which part of the Dropbox client you want to recreate. It is not my opinion, but from Explorers' view it makes sense; your file's status is not relevant to the user until he requests that file. Before it can be requested, the status is requested. Explorer will still show the files, just not the correct status initially. You can see this happening visually on a slow computer when the first overlay-icon is the blue refreshing-arrows when first opened, and than the actual status with the correct overlay-icon once the status is requested. Now, real-time is reserved for anything that is updated within 1/24 of a second, as that is what the human eye perceives as real-time. I don't care what framework you use, if it is on Windows, it will be as realtime as the idiot that ran a marathon just to deliver a message.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
You should reconsider WCF. Yes; once you get the settings right, "save" them. Other than that, we have lots of services communicating with different third parties exchanging multi-megabyte compressed payloads (shipping documents and label images) asynchronously from multiple locations.
I would really prefer to use WCF, but I can' seem to get past the exceptions I'm getting. This weekend I'll post it here so we can continue this. Thanks
If it's not broken, fix it until it is
-
I would really prefer to use WCF, but I can' seem to get past the exceptions I'm getting. This weekend I'll post it here so we can continue this. Thanks
If it's not broken, fix it until it is
My usual approach is to get a trivial case going and then expand upon it if I don't have a working solution already. Getting Started Tutorial[^] I've done the above previously and it works. One area that does cause confusion is "test versus live"; where you're usually communication over HTTP versus HTTPS. Maintaining dual settings is an issue; but one can "clone" live endpoints and modify them on the fly for test endpoints; or vise-versa (you can't construct them from scratch AFAIK). That's if you're dealing with multiple servers. In other cases, the 3rd party may just use different credentials for testing with the same endpoint.
-
My usual approach is to get a trivial case going and then expand upon it if I don't have a working solution already. Getting Started Tutorial[^] I've done the above previously and it works. One area that does cause confusion is "test versus live"; where you're usually communication over HTTP versus HTTPS. Maintaining dual settings is an issue; but one can "clone" live endpoints and modify them on the fly for test endpoints; or vise-versa (you can't construct them from scratch AFAIK). That's if you're dealing with multiple servers. In other cases, the 3rd party may just use different credentials for testing with the same endpoint.
I followed this article[^]. It works ok as is, but trying to expand on it gives me fits. See my post following this one where I outline the project requirements.
If it's not broken, fix it until it is
-
I followed this article[^]. It works ok as is, but trying to expand on it gives me fits. See my post following this one where I outline the project requirements.
If it's not broken, fix it until it is
I learned early on to create a class library / dll for every 3rd party service; including the "corporate" one. Already had to swap out one vendor for another; took a few hours. The sample you referenced should be refactored; too much UI code polluting the WCF code space.
-
I learned early on to create a class library / dll for every 3rd party service; including the "corporate" one. Already had to swap out one vendor for another; took a few hours. The sample you referenced should be refactored; too much UI code polluting the WCF code space.
I completely agree.. Like I said, coded as is it works fine.. When I refactor for my app I get all manner of strange errors. Mostly duplex related. I'll try again and repost with error details. Did you see my other post above? Curious on your thoughts.
If it's not broken, fix it until it is
-
I'm not sure if I agree with that. From what I can see that's the whole point of WebSockets, and SignalR which is built on it - to maintain a connection to the clients for e purpose of real-time communication.
zephaneas wrote:
From what I can see that's the whole point of WebSockets, and SignalR which is built on it
We either have a nomenclature issue or you are mistaken about what websockets do (I know nothing about the second.) Communication involves two parts 1. Establishing the connection 2. Sending messages. In normal communications, like web traffic a client (from any computer, any application) attempts to 'connect' to the server (any computer and server applications.) Websockets allow a client to create a connection to a server and then facilitate message handling (2 in the above) between the client and the server. A real callback requires a reverse of that connection protocol in that the server would then need to do 1 by attempting to connect to the original client. Websockets do not do that. Some reasons for clients not doing real callbacks. 1. The server cannot in fact connect to the client. Although a client might have a route to a server the server is not likely to have a route to the client. Nor even know how to connect to the client. This is much, must more likely to be true on the internet. 2. Servers are intended to be static resources. Clients are temporary. Thus even if a server attempted a callback the client might no longer be there. 3. Establishing connections can be a resource intensive process as is handling connections. Asking a server to do both, when a client is likely connecting to the server often in the first place is a pointless waste of resources. Not to mention adding complexity to the system.