Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support encoding.BinaryMarshaler types #75

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

stevvooe
Copy link

@stevvooe stevvooe commented Dec 3, 2014

Sending time.Time values over libchan has resulted in panics. This is a core
type and correct handling of the time type in libchan is important. By adding
support for types that implement encoding.BinaryMarshaler, we get support for
time.Time along with other types that implement this interface.

At first, it was unclear why this correctly worked, but closer examination
showed that this is supported within the codec package. The main bug was in the
handling in the (*pipeReceiver).copyValue method and its spdy equivalent. The
value copier really needs to be generalized and ported to work with any libchan
implementation to avoid such bugs in the future.

Sending time.Time values over libchan has resulted in panics. This is a core
type and correct handling of the time type in libchan is important. By adding
support for types that implement encoding.BinaryMarshaler, we get support for
time.Time along with other types that implement this interface.

At first, it was unclear why this correctly worked, but closer examination
showed that this is supported within the codec package. The main bug was in the
handling in the (*pipeReceiver).copyValue method and its spdy equivalent. The
value copier really needs to be generalized and ported to work with any libchan
implementation to avoid such bugs in the future.
@stevvooe
Copy link
Author

stevvooe commented Dec 8, 2014

@dmcgowan It might be better to use TextMarshaler for the time type or define a msgpack extension type for this functionality.

Note that this is blocking ipc support in v2 registry: docker-archive/docker-registry#831.

@mcollina
Copy link
Contributor

mcollina commented Dec 8, 2014

I'm in for an extension type for times.
Il giorno lun 8 dic 2014 alle 22:32 Stephen Day notifications@github.com
ha scritto:

@dmcgowan https://github.com/dmcgowan It might be better to use
TextMarshaler for the time type or define a msgpack extension type for this
functionality.

Note that this is blocking ipc support in v2 registry:
docker-archive/docker-registry#831
docker-archive/docker-registry#831.


Reply to this email directly or view it on GitHub
#75 (comment).

@dmcgowan
Copy link
Contributor

+1 on defining an extended type for time. @stevvooe is this currently blocking any implementation or is using string a good enough work around for now? If it is we should discuss what the extended type definition is and get a PR to the spec and implementation.

@stevvooe
Copy link
Author

@dmcgowan If we change this diff to use TextMarshaler instead, I think it will meet the needs for now. Would you like me to file a ticket for "native" time support?

@stevvooe
Copy link
Author

stevvooe commented Feb 3, 2015

What was the conclusion here? Did we want to just use TextMarshaler?

distribution/distribution#28 is pending a resolution here.

@dmcgowan
Copy link
Contributor

dmcgowan commented Feb 3, 2015

The code updated in this PR will be deprecated by #79. Do you have a timeframe for needing this feature? I will close it when the other is ready and merged. If you need it sooner we can discuss merging, I just want to ensure this doesn't require doing something special by the caller.

@stevvooe
Copy link
Author

stevvooe commented Feb 3, 2015

I was just cleaning house in docker/distribution. I can link distribution/distribution#28 #79, instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants