Hi, I'm Łukasz Raszka - also applying for the very same project. I wanted to address some of the concerns.
> Out of curiosity, why is repo tool by Google not suited here?
IMHO because of plugins. The idea is not only about making a git tool, but something extensible and more useful - for example making a plugin doing "du -sh" in the background, or maybe viewing quota when you want to tidy up your home directory (as stupid as it sounds). This gives many possibilities - more or less sensible. Some easily done in your .bashrc, but not necessarily.
> Here your libgit solution could help, but how
> would this scale to more plugins without a large performance penalty?
Plugins shouldn't work all at the same time, unless there's a specific need. After all, how much useful information can you put into the prompt? Daemon should run idle until some kind of virtual environment (kind of like virtualenv which most of you probably know) script is run, forcing it to load eg. the git plugin. Maybe you could load another plugin and concatenate the results, but I suppose not more than 2-3 of them. Performance wouldn't be an issue considering the architecture - maybe rather the nature of plugins - some being heavier, like git or that svn beast could become, while other, like forementioned quota viewer being much lighter.
> And ahead of time: sounds like
> it could become a second tracker/beagle desaster caching tons of unused
> data being one more nuisance...
> it could become a second tracker/beagle desaster caching tons of unused
> data being one more nuisance...
That's entirely possible. But on the other hand, you might need to enter the commands like 'git log' to achieve the same result, wasting your and CPUs' time, and plugins might be smart enough to watch directory tree for changes, so that they wouldn't do unnecessary grinding. Hard to foresee.
> The preferred way for me is "something from bashrc/etc."
> However, I don't know how to change prompt dynamically when user> doesn't run any commands/press keys.
IIRC, zsh has some facilities allowing it to be done; I don't think it'd be a good idea, though. Personally, I just like the reactive prompt better than proactive one - it's not that good to stop in the middle of typing because something changed - especially in case such as this, when daemon actions ought to be passive in their nature (providing status information rather than actually doing anything). And there's always the line feed if someone wants updated info.
Thanks to Mikołaj and Alexander for explaining the idea!
Regards,
Łukasz
2014-03-30 10:41 GMT+02:00 Alexander Mezin <mezin.alexander@xxxxxxxxx>:
2014-03-28 23:24 GMT+07:00 Tim Niemueller <tim@xxxxxxxxxxxxx>:
> In general, do you intend to extend the bash, or have something startedThe preferred way for me is "something from bashrc/etc."
> with the bashrc/profile/your-shell-file-here?
However, I don't know how to change prompt dynamically when user
doesn't run any commands/press keys.
Maybe both ways could be implemented: patch/extension for shell, and
something that generates PS1 every time as fallback.
Though I don't think bash devs will be happy to accept such patch.
Mikolaj, what do you think about it?
Actually, performance problems is what I personally want to solve in
> One typical complaint
> about stuff executed each time to form the prompt is that it can slow
> things down considerably. Here your libgit solution could help, but how
> would this scale to more plugins without a large performance penalty?
> Maybe some info about the architecture this would use could help here.
this project.
Daemon loads only once, so loading a lot of plugins shouldn't be a problem.
I didn't try to think about architecture yet. Designing good
architecture is a part of the project, and I will start working on it
only after I will have everything working for git.
However, I don't think there will be something complex.
D-bus isn't neccessary here. Socket should be sufficient.
> The daemon idea shounds sensible, talking via dbus?
Actually, answer to this question is at beginning of the message.
> Still, how would this be integrated with the command line.
As I noted in my proposal, the only way I see here is trial-and-error.
> And ahead of time: sounds like
> it could become a second tracker/beagle desaster caching tons of unused
> data being one more nuisance...
But I am sure something will work.
It's boring when everything is clear from the beginning, isn't it?
> I do think this is useful, there are just so many questions and details
> unclear currently.
_______________________________________________
summer-coding mailing list
summer-coding@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/summer-coding
_______________________________________________ summer-coding mailing list summer-coding@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/summer-coding
