Forums : Suggestions for Ohloh 2.0
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
How difficult is to write source repository plugin for Oloh?
We would like to write and contribute a plugin for Ohloh to access our quite specific repository of Ultrastudio.org.
When planning our project, we made a (maybe now questionable) decision to use releases in the form of subsequently uploaded .zip archives. The rational was that we aim also to less experience developers that may have difficulties contributing to real content repository as CVS or SVN.
Hence there is no tool like SVN on http://Ultrastudio.org and Ohloh keeps showing there is no code. However otherwise it is rather complex server with good internal access to all data that could easily serve you XML documents with structure of your choice or something the like. We can implement such plugin as we are also interested in this. From https://www.ohloh.net/api/getting_started your seem already using something similar to connect to Ohloh itself.
Do you have some communication standard that you thing would be easy to support? Would it be possible to discuss about this?
Java applets are normally not big. They usually contain two to five or six classes, at most several hundreds lines of code each. There are some bigger applets with more code (20 classes or about). We currently have 32 applets and we keep adding several every week. The biggest applet is currently BABA
that can be launched in five different ways to demonstrate five key algorithms of the bioinformatical sequence analysis. Configured with parameters, it shows up differently if five different articles, one per algorithm. However this does not look desireable. The idea is to have many applets, covering various areas of educational visualization rather than having several very complex applets.
The server already has code reviewing system that can list projects, list releases for every project, list all files in every release and retrieve the contents of any file. All this is currently converted into HTML for a browser but we could also serve XML response that would not be difficult to parse on another side.
Putting all code into one single repository may be difficult for licensing reasons. They are under various licenses that while all more or less FOSS, may not be fully compatible, so different folders would contain code under different licenses. Also, it would be purely artificial aggregation as there are no dependencies nor single startup point between the applets.
There is actually one API that Google uses. See http://www.google.com/support/webmasters/bin/answer.py?answer=75225. Maybe we could support this one?