TroveSendTwo Design Spec.

First things first.

The first objective should be to obtain a diff on setup project listings. For now we'll assume that a developer has gone through the initial work of obtaining permission to have a listing at Freshmeat and/or Sourceforge and/or Savannah (not Trove based yet) and/or OpenSource Directory and/or Berlios.

Via SSL: So the client should begin by: obtaining info from the project listings and report back a diff. This is to make sure that information across sites is at least consistant. If there are inconsistancies such as:

  • Project Trovesendtwo at SF reports: beta
  • Project Trovesendtow at OSD reports: stable
  • Please advise of change to make...........................
  • Inconsistancies are more prevalent than you'd think!
  • I would suggest working from the OSD metadata (info in a project listing including trove categoies-software map info & additional info) as a starting point since it is built from and upon SourceForge. ie. we track everything SF does, but, more. There will be data that the client will gather from some sites that others will not list.

    Then the client should be able to log into (via ssl,ssh?) the designated sites, login, make the changes, and logout. Being able to login and make changes is really a secondary step in development, but this is the idea. 8^)

    The second step step is making changes to a product listing. I'm going to say that the current release version is likely the most often to change piece of data so let's go with that. Now, all sites have the same data, but its time to update them. We start up the client which should start by telling us what the last 'snapshot' of our project looks like & with who. We can then update the listing on the client from ver .9beta to .9stable or however this will look (Some changes made will automatically change other data like, now we have a latest release version that matches the latest stable version which aren't always the same. Once we have a new non stable version these will change again).

    Now, tell the client to go login to the designated sites, make the changes, logout & report any errors writing to the sites. Perhaps SF is down? A cool feature may be to give an at command to try again in an hour to update SF? That's for later.

    Random thoughts on this first fuctional stage:

  • This should be developed with hopes of running across platforms, but linux first since serious development for trove based sites is being done on *nix's
  • It will have to actually check against the html version of the listings since that is the only consistant & live thing format across the sites.
  • It has to be done securely
  • How to add a new site that wants the data (must be trove based, I'd think)
  • Trovesend can actually help in developing a consistant trove software map.
  • The client should IF possible check for new datafields!