oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <simo...@apache.org>
Subject Re: APIs
Date Tue, 15 Jun 2010 14:17:55 GMT
Hi Simo,
obviously current SVN *is* the starting point.

Let's see how to continue on that line, if there are other proposals, if
some of our other existing code bases approach in a different way, or if
someone foresees some other kind of problems in integrating the current API
with their app.

Simone

2010/6/15 Simone Tripodi <simone.tripodi@gmail.com>

> Hi Simo,
> currently in the current svn Amber repo there is the signature (with
> implementation) and part of consumer APIs I wrote time ago for the
> Lab.
> They are still valid IMHO and part of my proposal, parts of code could
> be extracted from there.
>
> Feel free to ask questions if some parts are not clear.
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>
>
>
> On Tue, Jun 15, 2010 at 2:21 PM, Simone Gianni <simoneg@apache.org> wrote:
> > Hi all,
> > so, one part of our roadmap are APIs.
> >
> > Each of us has his own idea of how an API should be, in general, and many
> of
> > us already have an idea (or even code) on how an OAuth API should be :)
> >
> > There is no "absolute way" to determine if an API is better or worse than
> > another. It mostly depends on use cases.
> >
> > Amber will (as many other systems) interact with :
> > - external applications/frameworks, using Amber to integrate oauth
> > - internal extensions, providing for example different token storages or
> > interation different backends
> > - modules of Amber itself
> >
> > I think it would be better to focus on the first API now : which use
> cases
> > do we plan? How do you imagine the code of a web framework using Amber
> look
> > like?
> >
> > If there are very different cases there is space for more than one API,
> for
> > example a low level one and high level Fa├žade. Since our goal is to unify
> > different (often existing) pieces and ease the path of adoption on
> projects
> > that were planning to integrate OAuth, we'll need a bit of flexibility.
> >
> > Cast your code sample ideas :) People in projects that already use their
> own
> > implementation of OAuth can easily post real code.
> >
> > Simone
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message