'An API for sharing' meets Stuffarium
12 views
Skip to first unread message
matslats
Jun 20, 2011, 9:01:02 AM6/20/11
to API for sharing, Henri Laupmaa, René Lasseron, Reigo
Juho et al,
I've been thinking through what we need in Community Forge and
reflecting on the Stuffarium that Community Tools has already
prototyped, and I have sketched out a design below which I think will
meet many needs and which doesn't exist yet. The system is intended to
be a central service, without a web front end even, for registering
items of stuff and managing their loans, and to be accessed by
participating member web sites via a web API.
Each item has a privacy setting which indicates whether it can be seen
in searches coming from other sites. The central system does not
attempt to contact members directly but forwards expressions of
interest to the local system. This design facilitate all kinds of
loans, rental, gifts, including of shared resources in time slots. The
owner of the item decides the terms on which it is made available.
Most of the work should be done by the local machine, and this service
is only intended for centralised data storage. In my drupal module I
have implemented another API for managing payments, but that's a
different story.
I'm by no means an API developer or official documenter of such
things, nor a trained or even very experienced architect. What follows
is a technical interpretation of what to me is a clearly defined need,
which many many commercial attempts like rentalic.com are attempting
to meet as an isolated need. However we no longer need to pay 3rd
parties to broker our transactions, and we don't want to have a
website with a different global community for every need. We just need
to make the right software once and for all. If something close to
this gets built, I'll make sure it is supported by a Drupal module,
even if I have to write it myself.
I look forward to your comments.
Matthew
Database tables
'STUFF'
StuffID (serial)
title
description
pic (optional)
ownerID
ownernetwork ID
visible_outside_network Boolean
price
rate (hourly|daily|weekly|monthly)
currencyID
destination (owner|transferee|anywhere|community centre)
geocoordinates
condition (text)
Category Food|Living space|transport|recreation|community|professional|
learning|wellbeing|technology|care
'STUFF_TRANSFERS'
TransferID
TransfereeID
TransfereeNetworkID
ItemID
transfertime
returntime (optional)
state (reserved | in use | completed)
API functions
register_stuff(properties...)
update_stuff(properties including ID)
view_stuff(ID) returns data about stuff and current loans
search by text, position, category and radius, & pager
register_interest(StuffID, userID, times)
cancel_interest(StuffID)
loan(TransferID) changes state of transfer
return(TransferID) returns price to be paid
Local user interface
Example local form to register new stuff...
Here is a shareable item [title], [image]
Its mine, to rent | the price is X | per hour | return to me
It's yours for | the price is X
It belongs to everyone | return to user X
The price is X (optional)
one loan period is [period] (optional)
Notes on condition...
This item is already reserved by whoever - show calendar.
Example local form to register one's interest in stuff...
Item is shown. who owns it, and who is holding it, if different.
I need this item!
delivered to where&when | I can pick it up where&when -> mail to
holder
Between these times X and Y
Other user stories which should be supported by the above.
1. UserA registers item, and the terms of its availability
2. userB registers interest in the item and a mail is sent to userA.
They arrange the transfer
3. UserA or UserB marks the item as having changed hands.
4. if its a loan, reminders are sent by mail towards the end of the
loan period
5. if its a loan, either user marks the item has having been returned.
6. A transaction is registered, for the specified amount, and signed
off by both parties (or otherwise, according to transaction workflow)
I've been thinking through what we need in Community Forge and
reflecting on the Stuffarium that Community Tools has already
prototyped, and I have sketched out a design below which I think will
meet many needs and which doesn't exist yet. The system is intended to
be a central service, without a web front end even, for registering
items of stuff and managing their loans, and to be accessed by
participating member web sites via a web API.
Each item has a privacy setting which indicates whether it can be seen
in searches coming from other sites. The central system does not
attempt to contact members directly but forwards expressions of
interest to the local system. This design facilitate all kinds of
loans, rental, gifts, including of shared resources in time slots. The
owner of the item decides the terms on which it is made available.
Most of the work should be done by the local machine, and this service
is only intended for centralised data storage. In my drupal module I
have implemented another API for managing payments, but that's a
different story.
I'm by no means an API developer or official documenter of such
things, nor a trained or even very experienced architect. What follows
is a technical interpretation of what to me is a clearly defined need,
which many many commercial attempts like rentalic.com are attempting
to meet as an isolated need. However we no longer need to pay 3rd
parties to broker our transactions, and we don't want to have a
website with a different global community for every need. We just need
to make the right software once and for all. If something close to
this gets built, I'll make sure it is supported by a Drupal module,
even if I have to write it myself.
I look forward to your comments.
Matthew
Database tables
'STUFF'
StuffID (serial)
title
description
pic (optional)
ownerID
ownernetwork ID
visible_outside_network Boolean
price
rate (hourly|daily|weekly|monthly)
currencyID
destination (owner|transferee|anywhere|community centre)
geocoordinates
condition (text)
Category Food|Living space|transport|recreation|community|professional|
learning|wellbeing|technology|care
'STUFF_TRANSFERS'
TransferID
TransfereeID
TransfereeNetworkID
ItemID
transfertime
returntime (optional)
state (reserved | in use | completed)
API functions
register_stuff(properties...)
update_stuff(properties including ID)
view_stuff(ID) returns data about stuff and current loans
search by text, position, category and radius, & pager
register_interest(StuffID, userID, times)
cancel_interest(StuffID)
loan(TransferID) changes state of transfer
return(TransferID) returns price to be paid
Local user interface
Example local form to register new stuff...
Here is a shareable item [title], [image]
Its mine, to rent | the price is X | per hour | return to me
It's yours for | the price is X
It belongs to everyone | return to user X
The price is X (optional)
one loan period is [period] (optional)
Notes on condition...
This item is already reserved by whoever - show calendar.
Example local form to register one's interest in stuff...
Item is shown. who owns it, and who is holding it, if different.
I need this item!
delivered to where&when | I can pick it up where&when -> mail to
holder
Between these times X and Y
Other user stories which should be supported by the above.
1. UserA registers item, and the terms of its availability
2. userB registers interest in the item and a mail is sent to userA.
They arrange the transfer
3. UserA or UserB marks the item as having changed hands.
4. if its a loan, reminders are sent by mail towards the end of the
loan period
5. if its a loan, either user marks the item has having been returned.
6. A transaction is registered, for the specified amount, and signed
off by both parties (or otherwise, according to transaction workflow)
Kusti
Jun 23, 2011, 12:56:18 PM6/23/11
to API for sharing
Hi Matthew,
As a quick look, the description sounds quite nice. However, from our
point of view, we probably do not have resources at the moment to
change Kassi so that it would use this type of community forge as the
central store of listings. That's why I'm pushing the API definition
first, since the API can be used by Community Forge and all the other
services. But if you are set out to build such repository anyway, that
sounds very good!
I just posted a reply to the original chain about the API. I put
together a wiki page where all this stuff can be formally organized. I
put some notes there that follow your ideas, but also keeping in mind
that besides having a central repository, the API should also be
usable as such for services that have their own content repositories.
The site is now at http://www.sharingapi.org , please have a look and
edit as you will. I think that the community forge plan could have
it's separate page, since it also has components that might differ
from the basic API spec. What do you think?
Juho
As a quick look, the description sounds quite nice. However, from our
point of view, we probably do not have resources at the moment to
change Kassi so that it would use this type of community forge as the
central store of listings. That's why I'm pushing the API definition
first, since the API can be used by Community Forge and all the other
services. But if you are set out to build such repository anyway, that
sounds very good!
I just posted a reply to the original chain about the API. I put
together a wiki page where all this stuff can be formally organized. I
put some notes there that follow your ideas, but also keeping in mind
that besides having a central repository, the API should also be
usable as such for services that have their own content repositories.
The site is now at http://www.sharingapi.org , please have a look and
edit as you will. I think that the community forge plan could have
it's separate page, since it also has components that might differ
from the basic API spec. What do you think?
Juho
matslats
Jun 23, 2011, 7:06:21 PM6/23/11
to API for sharing
On Jun 23, 6:56 pm, Kusti <juho.makko...@gmail.com> wrote:
> we probably do not have resources at the moment to
> change Kassi so that it would use this type of community forge as the
> central store of listings.
Forge to be the central repository. Such platforms need to access a
3rd party repository. I'm hoping someone will build that repository.
That's why I'm pushing the API definition
> first, since the API can be used by Community Forge and all the other
> services. But if you are set out to build such repository anyway, that
> sounds very good!
build this, I will bring users. As far as I'm concerned, Kassi doesn't
need a user interface or even a marketing strategy. It just needs to
implement a web api
> I just posted a reply to the original chain about the API. I put
> together a wiki page where all this stuff can be formally organized. I
> put some notes there that follow your ideas, but also keeping in mind
> that besides having a central repository, the API should also be
> usable as such for services that have their own content repositories.
that involves your software talking to many other kinds of software,
which requires a lot of engineering, especially once you start to
address issues of synchronisation and privacy.
> The site is now athttp://www.sharingapi.org, please have a look and
> edit as you will. I think that the community forge plan could have
> it's separate page, since it also has components that might differ
> from the basic API spec. What do you think?
I think the stuffarium will implement user stories that you don't have
> it's separate page, since it also has components that might differ
> from the basic API spec. What do you think?
to worry about, and that don't belong in this space.
I've edited the page
Reply all
Reply to author
Forward
0 new messages