IT Mill Toolkit Directory - Request for Comments

How to organize sharing your re-useable toolkit code? How to re-use others code? How to learn from others? How to see what people have done with IT Mill Toolkit?

In order to answer these questions, please read my proposal:
http://dev.itmill.com/wiki/Directory

And comment it on this thread.

I immediately started envisioning a shopping basket type of system for widgets, where you’d add any and all widgets you like and the system would compile a widgetset for you ready to use in any IT Mill Toolkit application…

A bit on the ambitious side, but I like it :slight_smile:

When is it done?

/Jonatan

Actually this is just a basis that could make a lot of fancy stuff possible:

  • Showcase contributed widgets in feature browser
  • List contributed widgets in Eclipse plugin with automated download
  • Drag-n-drop the widgets to wysiwyg editor in eclipse and add them automatically to your project at the same time

But before this we need a some groundwork to make this possible. I hope that my proposal could be the first iteration of this groundwork…

A great initiative and a good start.

Here is some ideas to make things more flexible in the future with a target to allow people in the external itmill community to maintain their own projects with minimal hand-helding.

  • Allow people to upload projects and update project information trough a web interface. (editing .xml is so old fashion)

  • Allow anyone that has registered to upload new projects / edit projects without having to contact the directory maintainer.

    The directory maintainer job should ideally mainly be deciding if something can be published to the public and if something should be deleted (for example wrong usage / copyrighted work). Until things are approved only the original owner can work with the project.

  • After someone has uploaded X (3?) approved projects, all his future uploads should be auto-approved (unless of course he misuses his privilege).

  • There should be many directory maintainers (to avoid bottlenecks)

  • Establish sub groups of projects and make trusted individuals maintainers of groups.

  • One should be able to access and browse projects without having to log in.

Regards,
Monty

Thanks for ideas. Adapted the proposal according to these ideas.

Sure. My first intuition was to keep the first iteration minimal by just having “XML-interface”, but writing a simple UI with Toolkit should is really straightforward. Maybe the UI should be there right from the beginning.

These can be made possible with the admin tool. Implementing this in plain SVN might be impossible or not practical.

I fully agree that we should try to get rid of any obstacles right from the beginning.

We just need volunteers for these. On the other hand - if it is not possible, there will be no volunteers. Anyhow - this is trivial to implement.

Sure, http://dev.itmill.com/svn/directory/ is already there. World-readable.

If there is UI tool for these, my opinion.

  • Allow registered community users to add new directories and edit own directories without any “contact directory maintainer first”. They should be auto-approved and instantly viewable. If usage is wrong, then remove it or if it’s really messed up, deny privileges.

[quote=Anonymous]
They should be auto-approved and instantly viewable. If usage is wrong, then remove it or if it’s really messed up, deny privileges.
[/quote]Innocent until proven guilty, that’s the right way to go.

[quote=Jouni Koivuviita]

A way to implement this:

  • Directory stored in SVN as proposed
  • Maintainers have direct rights to SVN as proposed
  • Admin UI allows “anyone” to do certain operations, like upload components, create directories, etc.
  • Index.html maintenance program is limited to “see” only approved components, components from authors without needing approcal and directories with approved components in them

Why not put the data in database? I would like to keep the data in SVN in order to make it versioned, keep the interface public (through http) and generally build over existing infrastructure. Anyone sees this as a bad idea?

My post. Posted accidentally without logging in.

I’m already dreaming that this evolves to something similar like sf.net or berlios.de but for toolkit related stuff only.
In nutshell: Register and you instantly get:

  • project listed
  • web page where you can describe project, list participants, info about licence etc…
  • basic forum and basic bug tracking
  • project mailing list
  • some version control system for all participants

[quote=Mauno]
In nutshell: Register and you instantly get:

  • project listed
  • web page where you can describe project, list participants, info about licence etc…
  • basic forum and basic bug tracking
  • project mailing list
  • some version control system for all participants
    [/quote]Hmm, sounds like we’re re-inventing the wheel again here. Could we somehow just use code.google.com to host different projects, and then build an integrator service that will gather all of them together?

[quote=Jouni Koivuviita]

We probably dont want to limit project licenses like google does. But again my opinion might differ what Joonas proposes. What I’m prefering is “accessible, fast, easy to use” solution for posting projects without futher politics.

  • Accessible: world readable though some catalog and version control.
  • fast: no “wait until proved and review by someone that might be on vacation”.
  • ease of use: add participant with few clicks.

I’m thinking in the same way as Mauno here. There should be a very simple logic to add a new project. Preferably auto-approved and removable if misused. This can of course be changed to e.g. auto-approve after one admin-approved project if the service is misused.

As this might not attrach thousands of developers or projects from the start the beginning should be as easy as possible. It can be tightened with moderators later on if required. I just think that most people will submit one or two components only at least in the beginning. If it proves to be a good service, surely more directory entries are created also.

[quote=Jonas Granvik]
I just think that most people will submit one or two components only at least in the beginning.
[/quote]I agree, to require three approved submits is quite much. One is enough for starters. We can moderate this thing pretty well in the beginning, so misuse won’t likely be a problem.

I fully agree. Let it be as free as possible. If there are problems, lets make it a bit more moderated.

I am only proposing to start a Directory. Google code could be really good place to place the component code into. Directory is just a pointer to google code / sourceforge / dev.itmill.com/svn / … repository.

That’s a great idea !

I would gladly contribute to any source repository :slight_smile:

Quentin.


In advance, let me apologize for the anal retentiveness of this comment. But…

While this is a good intention, I began to wonder about the licensing part from the US perspective, with all the trigger-happy litigousness. I don’t think we can allow any arbitrary license, or the hosting might breach some of the licenses.

For the extreme example, if my custom license would state "
IT Mill or any of its associates may not possess nor distribute this component or any parts or derivative works thereof
," (or, simply: "
all rights reserved
") should Directory automatically index the component with its source code, there’s an automatic breach of license.

Now, as mentioned above, I’m not seriously saying that this will be a lawsuit-magnet, I’m just saying out loud what I’m thinking. It might be good to set some boundaries to what the license should be.

Updated directory plan: http://dev.vaadin.com/wiki/Directory

If you have any thoughts, lets discuss them in this thread. The plan also has some business aspects as we try to be as open as possible. Please do not take them as “set” or “promised”, but as “brainstormed”.