So, I think the solution has to be that the user downloads my app,
installs it on their site, then registers my app as their own app with
dev.twitter. After which, they will receive their own key & secret
pair. They will then input their key & secret pair into my app which
is living on their site, stored in some configuration file or database
settings table.

This way I don't distribute my secret. They will have to store their
own key & secret pair, but this wouldn't be different than a site with
its own proprietary solution. The only stick point is that I will not
get any branding rights on their posts/tweets, as they will have
registered the app as their own and will be in control of the post
branding.

The other option is to host a tweet service somewhere in the cloud. My
app, installed on their site, would point to the service and they
would have to grant permission to the service to make the tweets to
their accounts. I like this second solution because it seems cleaner
for the end user to set up and get running. However, this would mean
that I would then be responsible for maintaining a service. And
frankly, that sounds like a drag on resources.

These two are the best solutions I can figure given the circumstances.
Normally, I would wait for Twitter to get this sorted, however, I
don't want to risk disappointing my user base when the August 16th
deadline rolls around.

Does these solutions sound viable or am I all wet?

Pros, cons, alternatives?

Thx.

On Jul 27, 7:18 am, Decklin Foster <deck...@red-bean.com> wrote:
> Excerpts from Michael Babcock's message of Mon Jul 26 19:28:15 -0400 2010:
>
> > So, I after spending the day looking through documentation,
> > developer's discussion and testing various OAuth code bits, it is my
> > understanding that there is no secure OAuth solution for open-source
> > PHP developers. But, the August 16th deadline is still looming.
>
> I am also concerned about this. Here is the response I got from support:
>
> "we're continuing to experiment with this feature, and have not made it
> available further. I apologize for the delay and inconvenience, but keep
> an eye on our developer talk group for future announcements."
>
> I have been watching this list for about a month (prior to checking with
> support) in case the feature is discussed here before being announced.
> @twitterapi, could we get some clarification on whether or not something
> will be ready before the August 16 deadline?

Reply via email to