• 1 First brainstorming ideas
  • 1.1 Basics
  • 1.2 Easy integration in existing systems
    • 1.2.1 Viewing a project (as it was + some tags)
  • 1.3 What to tag
    • 1.3.1 whole projects, packages, releases, single files
    • 1.3.2 collection of files
    • 1.3.3 parts within a source-file
  • 1.4 provide freely definable tagging-classes
  • 1.5 distinguish between tags from everybody to those from project-owners
  • 1.6 Administration
  • 1.7 Database

• Perl
• DBI

Source-Repositories consist of Packages / Releases / Versions / Files etc.

Each web-site has somewhere some code where the html is generated. This is the place where the following functions can be called:

• Display Project-Tags
• simple function with project-id as parameter that returns html

• Display Package-Tags
• simple function with “project-id:package-id” as parameter that returns html

• Display Package / Relases / File-Tags
• and so on

• any Identifier for what to tag is good here
• any delimiter is also fine (but has to be configured somewhere)
• depth may be configured or given as parameter (e.g. show only project-tags, but not the file-tags here)

• Possibility to submit a tag
• a) function that generates the code for tag-submission
• b) just write your own code as html-form (maybe even with javascript to pop-up if you like)

• Store tags
• As we don't want to go to some other page when a tag was submitted, we need a function that analyses the http-post/get variables for our information. This will also be a simple function-call that does just this and doesn't output anything (and of course won't do anything if no valid http-variables are found)
• If you like you can write your own AJAX-code that does a XMLHttpRequest to a different site where this function is located. Then we don't even have to redisplay the current page :)

For these each software repository already has unique identifiers. So no special work has do be done here. Just pass the identifier to the functions.

Could be done by adding the possibility to pass lists of above identifiers to the functions. We would then just associate the tag to each file in the list.

Could be done by passing line-number-ranges to files. But as files change, this would only work if we calculate hash-values of files and use those as identifiers.

A better solution might be to add tags into the code (e.g. for c):

//tagbegin:helloworld
void main() //tag:function:myfirstmain
{
   printf("Hello world!");
} // tagend:helloworld

• this will only work for developers with write-access to files
• any tag-classes could be added like: //tag:package:mymain (But we wouldn't know what 'package' actually means, those classes are just like tags, but their intention should be to describe what is tagged here)
• This would need to run a script over the source-codes to extract the tags. I'm not sure yet if we really need to parse the files, probably just seeking for appropriate patterns with regular expressions should work fine here! (And would include a great language-independence :)

As already described in tagging source-code directly, this sheme could be taken over to all tags by just saying, that a tag may consist of a description-tag of what kind/part of information is tagged, and then the tag itself:

• background image:transparent animation
• idea:displaying images with information in background while browsing the net
• functionnames:fancy but cool
• see also:<a href=“http://somedomain.org” class=“external free” title=“http://somedomain.org” rel=“nofollow”>http://somedomain.org</a>

This could be done by adding a tagger-group-id to each function-call. For example the following id's could be used:

• 0 - anonymous
• 1 - project owner
• 2 - registered users

Each Repository-Site probably knows this information and should be able to pass this to my functions.

Well, this will be a simple web-interface for the project-owners. Here tags and class-tags can be corrected, removed and reassigned.

Access-Restriction to this interface should be done however the site does it anyway :) (No user-management will be implemented here!)

The Database-Structure could be as follows:

   whatistagged  < n --------- n >  tag  < n ---------- 1 >  tag-class
                        |
                        |
                    whoandwhen

I'm not yet sure if this is really neccessary here, maybe the following (even simpler) structure is better here:

   whatistagged  < 1 ----------- n > tags

Here the tags-table also contains the who, when and class attributes.

Attributes: (id is always the primary-key given from the db)

• whatistagged
• id, what-id (what-id is the id like 245:453:7 for project 245 package 453 release 7, we could also add like 10 columns or recursive table-structures for this, but as for now the what-id could be seen to be atomic for our needs, even if project, package and file are included. )

• tags
• id, tag-text, tag-class-text, tag-added-by-group, date-of-tag-submission, whatistagged_fk

<< back