Represent Global IDs as URIs: globalid://basecamp/Todo/1234

[jeremy]

• Share Global IDs among collaborating apps and with non-Ruby/Rails code
• Well-known format with parsers & generators already implemented
• Pave the way to put verifier signature in the URI params, or e.g. a "?version=456" optimistic lock

Next steps:

• Beef up the URI parser
• Integrate signing into the URI
• Introduce a url-safe base64 #to_param

[rafaelfranca]

Should we add tests to make sure we are assigning the right URL parts to these instance variables?

[jeremy]

Yes. If we're positive on the direction (using URIs) I'll include a real parser as well 😁

[jeremy]

(An alternative is to use URNs, but they're wordier and don't have broad generation/parsing support like URIs.)

[cristianbica]

@dhh @rafaelfranca what do we do with this? Dhh said to merge globalid into rails in the activejob PR (seuros/actionmailer-deliver_later#6 (comment)) but if we're going to migrate the representation to URIs we should do it ASAP.
I personally like the URI idea :)

[seuros]

I like the uri idea aswell. We just have to add that to the changelog since it a breaking change.

[dhh]

Cristian, I’m game for @jeremy’s URI idea. So I say we polish that up as part of this. But @jeremykemper also suggested that we split this out in a separate gem entirely, so Sinatra and others can use it too. I like that idea. So basically just go with a separate “globalid” gem, and then have activejob rely on that.

On Aug 12, 2014, at 12:23, Cristian Bica notifications@github.com wrote:

@dhh @rafaelfranca what do we do with this? Dhh said to merge globalid into rails in the activejob PR (seuros/actionmailer-deliver_later#6 (comment)) but if we're going to migrate the representation to URIs we should do it ASAP.
I personally like the URI idea :)

—
Reply to this email directly or view it on GitHub.

[seuros]

I though about the separate gem, but Globalid depend on activemodel. If we embed it , then sinatra app will have just to require activemodel 4.2+

[dhh]

What does GlobalID need from activemodel? Could we disconnect it?

On Aug 12, 2014, at 12:30, Abdelkader Boudih notifications@github.com wrote:

I though about the separate gem, but Globalid depend on activemodel. If we embed it , then sinatra app will have just to require activemodel 4.2+

—
Reply to this email directly or view it on GitHub.

[seuros]

.id

[dhh]

We can just have a protocol, imo. That requires that anything that mixes in GlobalID has to provide these things.

[seuros]

I had implemented something in #10 but it was rejected.

[cristianbica]

GlobalID needs .id on the instance and .find on the class. If we are going to make the GlobalID backend agnostic then GlobalID will be a mixin. We could go the acts_as_* way and have something like:

class ActiveRecord::Base
  global_identificable by: :id, finder: :find
end

and with the URI stuff it looks pretty good to me

[dhh]

I don’t even think we need to make those configurable at this point. We’re just putting out the contract that to use GlobalID, you have to have an #id and a #find method.

Then we’ll include GlobalID directly into ActiveModel in the activemodel gem.

On Aug 12, 2014, at 13:51, Cristian Bica notifications@github.com wrote:

GlobalID needs .id on the instance and .find on the class. If we are going to make the GlobalID backend agnostic then GlobalID will be a mixin. We could go the acts_as_* way and have something like:

class ActiveRecord::Base

global_identificable by: :id, finder: :find
end
and with the URI stuff it looks pretty good to me

—
Reply to this email directly or view it on GitHub.

[seuros]

@jeremy can you rebase and merge this PR ?

[jeremy]

@seuros Yep. I have a few more points to complete before merge.

[cristianbica]

Actually you're right. When we'll find someone who wants GlobalID and uses id/find for something else we will implement

[jeremy]

Moved to #17 based on the uri branch in this org instead of mine.