Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direction of onedrive for Linux #313

Closed
bugz8unny69 opened this issue Dec 24, 2018 · 11 comments
Closed

Direction of onedrive for Linux #313

bugz8unny69 opened this issue Dec 24, 2018 · 11 comments
Labels

Comments

@bugz8unny69
Copy link

hello

Foremost, I like to give credit to @abraunegg, there are alternatives to this client but the effort he has contributed to this project is beyond remarkable. And @norbusan that got interested, to make sure we safely sync our files!

With all that said, I have some disagreements, I believe, simple is better! For example, what is the point of this --get-O365-drive-id Query and return the Office 365 Drive ID for a given Office 365 SharePoint Shared Library

As a new user, why would I find that useful? I think that should broken up into a different project.

Other issue I have, is docker? Why? The effort to make it work in docker, just seems waste less? Maybe I don't understand why you want to run onedrive in Docker? What's the point?

I believe, we should be lock and step what Microsoft OneDrive does, deviate when necessary?

The problem I find with all these new command line feature is structure, 'why I would I use -x with -x'.

What I think, simple opendrive -h and put complex information in a man page?

@abraunegg
Copy link
Owner

abraunegg commented Dec 24, 2018

@LHorace
Certainly interesting feedback.

The client, when run 99% of the time is fairly simple - --synchronize or --monitor is all that is needed and your OneDrive account will get synced.

All additional switches are entirely optional - which were added either by direct feedback requesting functionality, or functionality which made sense & each should be fairly self explanatory as to why they exist - for example:
--download-only - Only download files
--upload-only - Only upload files
--no-remote-delete - Upload only, do not delete files on OneDrive that have been deleted locally
--single-directory - Sync just this directory, nothing else

Regarding your specific call out of --get-O365-drive-id - this was added due to implementing skilion/onedrive#302 which was rebased to this branch and implemented in PR #206. This whole 'merge' was all about supporting a sync from Microsoft SharePoint Libraries (ie - Business Shared Folders / Office 365) - which the original 'skilion' client did not support.

Now - if you read the original instructions in #206 on how to configure the 'config' file, many steps required & they were incorrect to a point - see #248. By having a simple CLI option to provide the right 'drive_id' saves not only time & effort, but also saves the user from an invalid configuration - see #293.

The problem I find with all these new command line feature is structure, 'why I would I use -x with -x'.

The current readme is fairly verbose with examples any why / when you would use the additional configuration options. The man page, likewise has similar if not more details.

If something is not clear then please call it out - patches / pull requests are welcome.

@norbusan
Copy link
Collaborator

Thanks @abraunegg for the good explanation. I don't see the need to reduce functionality, but I will try to make the man page a bit easier to read (first give basic usage examples, then the gory details). Also the output on error can be improved if we switch to the optdoc in future. I will also look into this.

@adudek
Copy link

adudek commented Dec 24, 2018

Other issue I have, is docker? Why? The effort to make it work in docker, just seems waste less? Maybe I don't understand why you want to run onedrive in Docker? What's the point?

@Ihorace
I want to address Docker part: its purely distribution simplicity, its easier to state docker run, than copy & install all dependencies. Additionally Docker is resource valuable for developers that want to tinker with onedrive and not mess their "working" setup or just pickup their work on different environments. I could go on about Docker more but reproducibility and containment are the keywords here.

Just to give you more reasons why, it would be nice to be able to execute test before push (shift left), so you could have faster feedback cycle, and not bother to setup test env for this. Currently docker gives you "just" ability to run onedrive, but its stepping stone for full dev/quality flow, with all logic abstracted and delivered inside.

@bugz8unny69
Copy link
Author

bugz8unny69 commented Dec 25, 2018

Foremost, I like giving feedback to projects that I support and like, so thanks for all your cordial responses.

Regarding your specific call out of --get-O365-drive-id - this was added due to implementing skilion#302 which was rebased to this branch and implemented in PR #206.

Now - if you read the original instructions in #206 on how to configure the 'config' file, many steps required & they were incorrect to a point - see #248. By having a simple CLI option to provide the right 'drive_id' saves not only time & effort, but also saves the user from an invalid configuration - see #293.

Technically speaking, I’ve been following every issue and commit since the beginning of March of this year. I completely understand why it was implemented, and regardless how my original comment might have sounded, I’m not against it. I think there are better ways this could have been implemented. It seems out of place there, a simple setup program, ie onedrive setup.

My original intent of this issue is not regarding onedrive in it’s current state but ideas/discussion to take into considering when planning and the eventual implementation of the rewrite. Avoid boilerplate code and do one thing and do it very well.

@adudek
Ahh, totally makes sense, then disregard my comment about Docker

P.S:

If something is not clear then please call it out - patches / pull requests are welcome.

Definitely, although, helping with code is not the only way to help contribute though.

@bugz8unny69
Copy link
Author

bugz8unny69 commented Jan 21, 2019

Reading #355 (comment) comment, there's a disagreement but never brought up to my attention. Nevertheless, I love open source, I will help where I can. However, since re-write is in a limbo and @abraunegg want to continue implement features and fixes based on Skillion code. This is still a good thing, because we have maintainers.

EDIT:

As for me, I was hoping for a re-write but I digress just accept what works.

@norbusan
Copy link
Collaborator

@LHorace FIrst of all I am not the main developer, so I cannot and will not decide on what will happen. I try to fix bugs, implement features, and suggest ideas. But at the end it is @abraunegg decision.

What big advantage would you see in a re-write? What are the aims you are targeting at? If you are so eager, please for the current repository and start the rewrite, and let us see what you envisage!

Thanks

@bugz8unny69
Copy link
Author

bugz8unny69 commented Jan 21, 2019

@LHorace FIrst of all I am not the main developer, so I cannot and will not decide on what will happen. I try to fix bugs, implement features, and suggest ideas. But at the end it is @abraunegg decision.

@norbusan Why do you feel that I thought you were the main developer? You help making this program better and I've been following it.

I will close this ticket since it's going nowhere.

What big advantage would you see in a re-write?

Make it your own!

I won't advocate for a re-write if I thought @abraunegg wasn't going to do one.

@abraunegg
Copy link
Owner

@LHorace
Re a 'complete re-write':

Some aspects of this currently client & how it is fundamentally written, the way it uses classes & functions today does not lend itself well to multi-threading activities. Being able to multi-thread correctly would mean being able to handle parallel uploads / download thus potentially a faster end user experience than today - esp when dealing with many small files.

Certain sections of the client would need to be re-written to support doing this as I have investigated a number of options here on how to do it - it is not a complete re-write per say - but would be a major engineering & testing effort and @norbusan is correct - this is something that there has to be time & energy for.

As for who is the 'main developer' - we all are - everyone who contributes by writing code, reviewing or testing changes, submitting bugs / feature requests - not just myself or @norbusan who I also thank greatly for the assistance provided over the last few months.

I am just happy that I am able to 'give something back' which is useful & less error prone to the wider community.

@bugz8unny69
Copy link
Author

I see you answer every goddam ticket, I see where you put in the effort, no answer

@bugz8unny69
Copy link
Author

I didn't want to use onedrive just as tool and recognize the effort you put in @abraunegg and @norbusan

I'll just lurk.

@lock
Copy link

lock bot commented Feb 20, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants