You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <br...@users.sf.net> on 2014/03/03 23:26:34 UTC
[allura:tickets] Re: #7208 DOAP API for projects
`.doap` looks better to me than `?doap` Too bad its difficult though. Maybe not.
I am -1 on using the `Accept:` header. I believe it is proper according to HTTP specifications, but it is just not very practical. It's *so* much easier to work with APIs if you can get what you want with just a URL and no special headers.
---
** [tickets:#7208] DOAP API for projects**
**Status:** in-progress
**Milestone:** forge-backlog
**Labels:** allura-api 42cc doap
**Created:** Fri Feb 21, 2014 10:04 PM UTC by Dave Brondsema
**Last Updated:** Mon Mar 03, 2014 08:45 PM UTC
**Owner:** nobody
Create a [DOAP](https://github.com/edumbill/doap/wiki) API endpoint for allura projects. I think the URL should be /rest/p/projectname?doap (open to better suggestions). It should be XML that is similar in format to SourceForge (classic) DOAP files like https://sourceforge.net/api/project/name/vivo/doap as much as possible. A number of fields in that are not applicable to Allura, so just don't include them. It is okay for Allura DOAP to continue to use some of the "sf" namespace elements like environment, database, etc (those are all the trove types of a project), as well as sf:awarded (for awards, use the current Allura award system available via neighborhood admin pages). `<maintainer>` is for each project Admin and `<developer>` is for each Developer on the project.
In addition to the basics, each tool should be able provide its own XML/RDF data to include. For example, SourceForge's internal mailman tool could provide `<mailing-list>` entries and Files tool could provide a `<download-page>` entry.
---
Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #7208 DOAP API for projects
Posted by Cory Johns <ma...@users.sf.net>.
I was suggesting allowing `Accept:` in addition to specifying the format in the URI, but I doubt it's worth bothering with.
Regarding `.doap` vs `?doap` (or `?format=doap`), I read an argument that `.doap` is significantly "worse" because the URI no longer identifies a resource, but a format / encoding of a resource. But we do have precedent for it, as I noted.
I'm not really keen on modifying the `NeighborhoodRestController._lookup` (which is where I think it would need to go to work) with code specific to the format of a single view, even if the code itself is relatively simple. It also raises the question of what happens when someone requests http://sf.net/rest/p/allura.doap/tickets (which, again, indicates that the URI should identify the resource, irrespective of format).
---
** [tickets:#7208] DOAP API for projects**
**Status:** in-progress
**Milestone:** forge-backlog
**Labels:** allura-api 42cc doap
**Created:** Fri Feb 21, 2014 10:04 PM UTC by Dave Brondsema
**Last Updated:** Mon Mar 03, 2014 08:45 PM UTC
**Owner:** nobody
Create a [DOAP](https://github.com/edumbill/doap/wiki) API endpoint for allura projects. I think the URL should be /rest/p/projectname?doap (open to better suggestions). It should be XML that is similar in format to SourceForge (classic) DOAP files like https://sourceforge.net/api/project/name/vivo/doap as much as possible. A number of fields in that are not applicable to Allura, so just don't include them. It is okay for Allura DOAP to continue to use some of the "sf" namespace elements like environment, database, etc (those are all the trove types of a project), as well as sf:awarded (for awards, use the current Allura award system available via neighborhood admin pages). `<maintainer>` is for each project Admin and `<developer>` is for each Developer on the project.
In addition to the basics, each tool should be able provide its own XML/RDF data to include. For example, SourceForge's internal mailman tool could provide `<mailing-list>` entries and Files tool could provide a `<download-page>` entry.
---
Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #7208 DOAP API for projects
Posted by Igor Bondarenko <je...@users.sf.net>.
I think we can implement `.doap`, it shouldn't be that hard.
---
** [tickets:#7208] DOAP API for projects**
**Status:** in-progress
**Milestone:** forge-backlog
**Labels:** allura-api 42cc doap
**Created:** Fri Feb 21, 2014 10:04 PM UTC by Dave Brondsema
**Last Updated:** Mon Mar 03, 2014 08:45 PM UTC
**Owner:** nobody
Create a [DOAP](https://github.com/edumbill/doap/wiki) API endpoint for allura projects. I think the URL should be /rest/p/projectname?doap (open to better suggestions). It should be XML that is similar in format to SourceForge (classic) DOAP files like https://sourceforge.net/api/project/name/vivo/doap as much as possible. A number of fields in that are not applicable to Allura, so just don't include them. It is okay for Allura DOAP to continue to use some of the "sf" namespace elements like environment, database, etc (those are all the trove types of a project), as well as sf:awarded (for awards, use the current Allura award system available via neighborhood admin pages). `<maintainer>` is for each project Admin and `<developer>` is for each Developer on the project.
In addition to the basics, each tool should be able provide its own XML/RDF data to include. For example, SourceForge's internal mailman tool could provide `<mailing-list>` entries and Files tool could provide a `<download-page>` entry.
---
Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.