Android Blog about open intents did not mention OpenIntents

[friedger]

Hi,

the latest Android Blog didn't mention OpenIntents. Please spread the
word between developers that OpenIntents is here to discuss and
promote your open intents.

In section "Publishing the Intent Specification" they say: "The answer
is simple: publish documentation on your website."

We think a central repository is much more effective. Therefore, we
created the open intents registry at www.androidintents.com. We are
working on an open API so these information are accessible by
everyone.

Cheers,
Friedger

[Friedger Müffke]

There is an interesting blog from the author of packrat about this issue:
http://packrat.unwesen.de/2009/11/not-integrating-application-with-intents/

Friedger

2009/11/12 friedger <frie...@googlemail.com>:

--
OpenIntents UG (haftungsbeschränkt)
Suarezstraße 41
14057 Berlin
tel:+49 30 60982220
mailto:in...@openintents.biz
enum:+493060982220

Vertretungsberechtigter Geschäftsführer: Friedger Müffke
Registergericht: Amtsgericht Berlin (Charlottenburg)
Registernummer: HRB 118597
Ust-IdNr: DE265992701

[Jens Finkhaeuser]

Hi!

On Nov 12, 9:31 am, Friedger Müffke <fried...@googlemail.com> wrote:
> There is an interesting blog from the author of packrat about this issue:http://packrat.unwesen.de/2009/11/not-integrating-application-with-in...

Thanks - now that I've contacted some of you about this, I realize
you've been working on this issue a bit longer than myself ;)

Here is, summarized, what I think needs to happen with an intents
registry:

1) We need a lightweight process for turning "drafts" into
"standards".
2) Documented Intents need to be marked as either draft or standard
(or any in-between state we might come up with)
3) There needs to be the possibility to comment on drafts, in order to
provide feedback before turning them into standards.

#2 and #3 are technical issues with the OpenIntents website that
should be reasonably easily resolved. What I'm not entirely sure of is
what process would be best for #1. Any ideas?

[Jens Finkhaeuser]

Oh, here's another one, with lower priority IMO:

There's a good chance that any Intent, however well it's documentation
might have been reviewed, will require further revisions. It's
probably a good idea to also document a best practice for marking
newer revisions of Intents.

Unfortunately, there are plenty of versioning schemes for libraries,
etc. out there already, and proponetns of each scheme will probably
argue about why their favourite one is best. I'm not really interested
in pouring oil on that flame.

So all I'd like to suggest is that
a) Intents should be versioned, and
b) a simple scheme such as "my.intent.name.versioncomponent" be used,
where the version component can be whatever you want.

Intent names are beautifully namespaced already, it only makes sense
IMO to have the most-specific/right-most part of the name represent
the revision of the preceeding parts.

Thoughts?

[Peli]

ad 1) Do you mean some formal process like voting or so? Or discuss
until everyone is satisfied? Or have a panel of experts who try to
ensure that intents are as simple and lightweight as possible, and
that additional customization is always possible through custom intent
extras?

ad 2) I agree, there should a solution for this in the new intent
registry that Friedger wants to create. There should also be a
distinction between "standard" and "implemented", because for
developers who want to use an intent, the most urgend question is if
an application exists already that can handle an intent.

Peli

[Peli]

As far as I understand, revisions are not intended for intents. Once
you have an intent standard, it is best never to touch it again. If it
requires modification, it was not a good intent in the first place.

Customization and expandability are always possible through additional
intent extras, but the basic intent should be simple and not require
modification (like VIEW + URI).

If the intent does not do anymore, it is probably better to define a
new intent altogether.

Peli

[Jens Finkhaeuser]

On Nov 12, 12:39 pm, Peli <peli0...@googlemail.com> wrote:
> ad 1) Do you mean some formal process like voting or so? Or discuss
> until everyone is satisfied? Or have a panel of experts who try to
> ensure that intents are as simple and lightweight as possible, and
> that additional customization is always possible through custom intent
> extras?

Oh, something simple. It should be formal enough that things reach a
resolution, but informal/lightweight enough that the resolution can be
reached fast.
One suggestion would be to have a voting period of e.g. X weeks,
during which >N votes need to be recorded and the draft gets turned
into a standard if the majority of the votes approves of the draft.
Voting can include suggestions for improvements, which can lead to a
new draft revision and a new voting period.
Boost has something of the sort (http://www.boost.org/development/
submissions.html ) - they're happy enough with it, I think.

> ad 2) I agree, there should a solution for this in the new intent
> registry that Friedger wants to create. There should also be a
> distinction between "standard" and "implemented", because for
> developers who want to use an intent, the most urgend question is if
> an application exists already that can handle an intent.

Good point!

> As far as I understand, revisions are not intended for intents. Once
> you have an intent standard, it is best never to touch it again. If it
> requires modification, it was not a good intent in the first place.
>
> Customization and expandability are always possible through additional
> intent extras, but the basic intent should be simple and not require
> modification (like VIEW + URI).

Maybe I view this from a slightly skewed perspective, but to me the
combination of Intent name and Extra name/value type describe an
interface, with the former being equivalent to a method, the latter
equivalent to parameters.
It's generally considered to be fine to add optional paramaters,
provided that leaving them out does in no way change the expected
behaviour. Once parameters become non-optional or change the expected
behaviour if not provided, you have an incompatible change to the
interface.
At that point, you can either come up with a completely new name for
that incompatible interface, or add a version number to it. It's
really much the same thing in that the combination of name+version is
the unique identifier, rather than the name being unique in itself.
But with name+version you at least signal that two unique identifiers
are related in concept, but not don't necessarily work the same way.

Jens

[westmeadboy]

Interesting discussion!

I'm not so keen on having a mandatory version because it feels messy.

If an intent evolves to that point where you would break backwards
compatibility (AND you don't want to create a brand new intent) then
you could always just add an optional parameter called "version".

[Jens Finkhaeuser]

> If an intent evolves to that point where you would break backwards
> compatibility (AND you don't want to create a brand new intent) then
> you could always just add an optional parameter called "version".

I'm all for optional! Just make it a well-published "best practice"
to add version components if you make incompatible changes.
I don't see a huge problem with versioning, at least not at the
moment. I'm just thinking ahead, and most systems that implement
interfaces of any sort end up with a form of versioning at some point.
Might as well bring it up now.

[Justin]

Full disclosure: I am a Google employee and the poster/co-author of
the blog post this thread refers to.

Re:standardization, formal standards are great, but I would err on the
side of caution with how quickly something is deemed a "standard". As
Android developers I think there's a great luxury in the lack of
rigidity required for Intents, its gives them time and scope to evolve
into the right form. As makers of the Android platform our Java APIs
have to be much more rigidly defined and standardized, but these are
also much more established for the most part. Intent-based APIs have
really low barriers to entry and can be this frothy, seething universe
where new functionality emerges, its key not to stifle this.

Instead, as suggested, I think feedback and rating mechanisms are they
key to helping these would-be standards evolve and stabilize.

I also think the version parameter is a good idea. In URI-based
schemes I think it makes sense as a GET parameter and if not present
the default behavior is to use the most recent version. For Bundle-
based schemes it should just have a well-known key value, "apiVersion"
perhaps.

Cheers,
Justin

[Friedger Müffke]

You can add comments to the intents protocol, e.g. in the print intent
at http://www.openintents.org/en/node/278 use the "add new comment". I
also added a status field that the author can change.

More improvements to come ...

Friedger

2009/11/12 Jens Finkhaeuser <unw...@gmail.com>:

[pjv]

I think I can see rigid standardization of intents coming in the far
future, but we should proliferate free app love at the moment :-)

My first thought would be the following states that need to be run
through: draft, concept, under change control (i.e. standard),
implemented, deprecated.

It would be so easy if we could keep versions out of the intents, but
I'm afraid that just won't be happening anyway, so better deal with
it. Don't forget that having clearly named intents (albeit with a
version number of sorts, rather than each time creating a new one) is
also worth a lot, for readability and overview's sake.

To add some oil to this thread's burning flame, the following article
didn't mention OpenIntents either:
http://www.androidguys.com/2009/11/02/a-call-to-action-action_send-that-is/,
luckily I see there is already another thread to remedy that.