Hosting files on Google Groups

[monsur]

Hi there. The Files page for Google Groups states:

"Google Groups will no longer be supporting the Pages and Files
features. Starting January 13, you won't be able to upload new
content, but you will still be able to view and download existing
content. See this announcement for more information and other options
for storing your content."

I was wondering if there were plans to host these files, especially
the JSON-RPC spec itself, somewhere else?

Thanks,
Monsur

[Matt (MPCM)]

I don't think any final actions have been taken yet, but some ideas
have been tossed around.

The group will make sure the docs are available as the time comes
closer, I am sure.

Personally I am on the other end of one apartment renovation and my
own wedding now, :). Got one more unit to deal with in the next couple
weeks, but I'll be able to step up and do something, one way or the
other after that.

I think these is a thread already started about this, if you have
suggestions for the managers to consider.

--
Matt (MPCM)

[Vladimir Dzhuvinov]

Congratulations, Matt!

I don't see much sense in Google's move to drop pages, but eventually
we'll have to act. Some people suggested using Google Code to host the
spec text and associated files. On first sight this suggestion seems
alright to me, but I have to say I've got no direct experience with
Google Code.

In any case I would very much like the spec to find a final and well
accessible place, as I've got a number of products based on JSON-RPC
2.0 already and need to be able to provide my customers with a good
and presentable reference. And now that the technical bits of 2.0 are
finalised, to clean up and finalise the spec text as well. I hope
we'll manage to get this done in the new year.

Vladimir

--
Vladimir Dzhuvinov :: software.dzhuvinov.com

[James Cooper]

Hi there,

New to the group, but interested in this discussion.  Seems like there's a few simple options:

(a) cloud hosted doc

- Google Doc (Read-only to public, Writeable by a select few)

(b) code hosting site w/wiki capability

- github

- google code

(c) full on web site / wiki

- hosted by someone on the list

---

(a) seems like the simplest migration path if all we want to do is get the google group file hosted somewhere.

(b) w/github is my personal favorite.  we could author the spec in Markdown (easy), and publish it out in PDF/HTML with pandoc.  github's pull request mechanism is excellent, and enables hierarchical peer review, which seems ideal for a project like this.

Happy to help with either option.

-- James

--

James Cooper
Principal Consultant - Bitmechanic LLC
http://www.bitmechanic.com/

[monsur]

I went ahead and added a copy of these files to a GitHub repo:

https://github.com/monsur/json-rpc

Feel free to fork for updates, etc. Also if anyone has a better
solution, by all means go for it; but this repo will suffice for the
time being.

Thanks,
Monsur

[James Cooper]

Excellent.  I just forked it.  Thanks for doing this.  Are you volunteering to be the head maintainer and we should issue pull requests to you?

-- James

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Louis Ryan]

I suspect google code or a wiki would be a more appropriate home for a documentation presence. Seems like we should propose some options and then have an open vote. I suspect folks would vote for whichever option someone volunteered to maintain :)

[Rasjid Wilcox]

On 7 December 2010 13:05, Louis Ryan <lr...@google.com> wrote:
> I suspect google code or a wiki would be a more appropriate home for a
> documentation presence. Seems like we should propose some options and then
> have an open vote. I suspect folks would vote for whichever option someone
> volunteered to maintain :)

I agree with Louis.

Personally I think GitHub is not the right place at all for a spec. I
think something like a spec needs to have a single well defined
presence, and having multiple public forks floating around is just
asking for trouble. A spec is not like code where it makes sense for
people to hack around on their own branches.

Cheers,

Rasjid.

[James Cooper]

There's nothing stopping the group from publishing specifications off of that tree that are immutable.  You could, for example, store the source document in restructured text, and generate PDFs from that.

The nice thing about github's infrastructure is that it has a very graceful workflow for accepting contributions from outsiders.  If someone wants to fix a typo or propose an amendment they have a very well understood way of doing that:  fork, edit, commit, pull request.   The maintainer(s) can decide whether the contributions should be accepted in a threaded discussion.  It's very slick.

This is why folks are starting to use it to manage community web site content.  It's basically a wiki with stronger editorial control.

So I still like github above the stated alternatives, but I will keep an open mind.

-- James

--

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Yitzchak Scott-Thoennes]

github would be fantastic for developing a specification, but isn't
necessarily a good place for final versions that people can link to.

I believe the final 2.0 specification is an html document (including
hyperlinks); finding a new home for it should not involve converting
it to some other format.

Just my 2 cents.

> +unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/json-rpc?hl=en.
>
>
>
>
>
> --
>
> James Cooper
> Principal Consultant - Bitmechanic LLC
> http://www.bitmechanic.com/
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "JSON-RPC" group.
> To post to this group, send email to json...@googlegroups.com.
> To unsubscribe from this group, send email to json-rpc

> +unsub...@googlegroups.com.

[Matt (MPCM)]

I'm split on github.... collaboration is good, though with git there is a view that change and correction are part and parcel, and that forking is the way to go.... I don't believe that is true for a specification as much as for code.

I worry that this would mean people looking to scratch an itch and for example add a 'mycustomsessionid' field to the request/response object, and would quickly pollute the name space. The reality is that this is already happening on some levels, I see no issue with having the official spec from this group being up on github though, in addition to being hosted from a more official url as well. I'm going to attempt to declare that this group though will remain the source of final decisions on the 'official' specification, whatever 'official' means in that sense.

Possibly having the json-schema of the request/response objects posted would allow a more transparent way for those extending the base spec with extension specs to specify the changes in data structures.

That only really would leave the handling/processing to be documented. That too can be automated and documented more, along with expected results for error conditions for example.

So, I am suggesting that we keep these groups for discussions, that github or other sources be setup by several people, and that we let things progress in a wider sense. We can keep the official spec posted here in a post, and keep other files elsewhere as well. Somewhat like we have code implementations scattered among several managers, members, and even non-members of this group.

With 2.0 being stamped, perhaps it is time to let this spread a little more freely and see where things settle?

--

Matt (MPCM)