Hi AJ,
I am fairly sure that rsync is not what I need:
1) The service is made for consumers, every consumer will get an auth
ID which they set in their software
2) The software can then upload files within the restrictions that
match this auth ID (eg. storage limit, bandwidth limit etc.)
3) The software has to run on Windows, Mac and Linux
What I need is a node.js server that keeps track of all clients
(consumers) and accepts incoming connections if they are
authenticated, then stores the files and offers files for download on
request etc.
Regards,
Tom
On 29 dec, 23:33, AJ ONeal <
coola...@gmail.com> wrote:
> Any particular reason not to use rsync?
>
> I've thought about this before and to me it seems that the simplest solution
> would probably be to use rsync and your backup backend and use node for
> storing configuration in a database.
>
> 1. I can't see any reason to not use TCP. You may be able to come up with
> some more efficient algorithm on top of UDP... but it's probably not worth
> it even if you could. It would just be more code that ends up under your
> maintenance.
> (You might go a step further and use HTTP)
>
> 2. I vote you store the files as files. If you were trying to build some
> sort of enterprise solution like what Mozy has you could investigate more
> fancy mechanisms once you have the basics in place.
>
> However, you may want a database to be able to search contents of files.
> MediaTags is a library I'm developing for the purpose of extracting
> meta-data from common data types.
https://github.com/coolaj86/mtags
> >
nodejs+un...@googlegroups.com<
nodejs%2Bunsu...@googlegroups.com>
> > .