[Json-rpc-java] [jabsorb-user] Re: Announcing jabsorb, a new JSON-RPC library!

sasha.ov at gmail.com sasha.ov at gmail.com
Tue Sep 25 15:12:04 SGT 2007


Michael --
> Users without gmail accounts (such as me) are unable to
>    contribute to the project among many other reasons (both practical and
>    idealogical) including the locking-in of all of the project artefacts
>    into a proprietary system.
Technically, you don't have to have gmail account -- it is enough to
have Google account.

If you want to test, go to http://www.google.com/accounts/NewAccount and
try to create one with your current (non-Google) email. There is help at
http://www.google.com/support/accounts/. After you created the account,
your email could be added to the list of project members/owners.

Also, you can  set up periodic backups of the SVN repository so the code
won't be locked in the proprietary system. Let me know if you need details.

So make your decision, gentlemen.

Ask me, Google Code is one of the smoothest repositories out there.

Also on the unification note, I wouldn't mind contributing my little
Java client (http://code.google.com/p/json-rpc-client/) to the unified
project if you guys are interested.

Regards,
-- Sasha

Michael Clark wrote:
>    Hi Arthur,
>    I think this is all great (except for the fork part) and I'm really
>    glad there are people interested in contributing and continuing this
>    project - and I have the  full intention to support this (as long as
>    it is not too my exclusion). In fact I will be much more interested to
>    participate having others actively participating too.
>    I would be really happy to be part of a bigger community project with
>    shared administrative control and I am completely happy with your
>    stated goals. My appreciation to you for standing up to give this
>    project some leadership.
>    I am comfortable with a package and name change (to jabsorb.org),
>    adding full administrative control for you and whoever else you need,
>    and adding a (MoinMoin) Wiki and Bugzilla issue database. I can even
>    give full shell access to a Linux server for hosting of the website
>    and demos with a tomcat instance (on a secure monitored server with
>    RAID1 storage and nightly backup). If we can agree on this approach I
>    could get this all up and running by 1st Oct.
>    As the only real issue I have with all of this is the use of google
>    code. Users without gmail accounts (such as me) are unable to
>    contribute to the project among many other reasons (both practical and
>    idealogical) including the locking-in of all of the project artefacts
>    into a proprietary system.
>    I personally would prefer to follow a more Apache-like model and also
>    to use similar infrastructure to them - they are using MoinMoin wiki
>    for all of their projects and they use Bugzilla as their issue tracker
>    (as do the majority of other Open Source projects).
>    If you are willing to let me provide an open infrastructure and set it
>    up in such a way as to grant autonomy to the project then please let
>    us know. I would prefer to be working with than with you against me.
>    We can discuss the details but I believe we can get us an open
>    infrastructure that will suit all of us better (including more open
>    access for you too).
>    Apologies for not getting back to you earlier on your mail about
>    future direction - I haven't completely disappeared - there was in
>    fact only *one* email from you that I missed replying to before your
>    decision to fork the project. You now have my attention :)
>    Best Regards,
>    Michael.
>    Arthur Blake wrote:
>
>      Hi Michael,
>      First off, none of this would have been possible without
>      JSON-RPC-Java, and we are very thankful that you created this great
>      library!
>      Having the main line continue and the fork at the same time is
>      obviously counter-productive if instead we can put our resources
>      together.  We've been operating under the assumption that the main
>      line is not continuing because the discussion on the mailing list
>      has trickled down to almost nothing lately, and you had seemed to
>      have disappeared.
>      I think we should examine the individual needs of JSON-RPC-Java,
>      jabsorb and the community, one point at a time to determine if a
>      reunification is necessary and desirable.
>      Here are my thoughts at the moment on the issue.
>      The primary reason for forking is the lack of clarity in project
>      direction and lack of ownership and authority in making executive
>      decisions-- at least with a fork, we know we are in charge, and can
>      freely do what we think is right.
>      For example, I know you gave me commit access to JSON-RPC-Java, and
>      I appreciated that, and even checked in some changes, but then
>      there was no direction on several other suggestions made, and no
>      direction on when we could expect the next release.  I for one need
>      these changes right away... at least with the fork now there is no
>      question of the release time line, because we set it ourselves!
>      Google code and Google groups provides us with a very nice
>      framework for hosting the library-- and it can have multiple owners
>      so that in the future, there is no one single person that will be a
>      bottleneck if someone has to leave the project, or can't put very
>      much time and energy into it for whatever reason.
>      It also has a lot of nice amenities for hosting the project, such
>      as bug tracking, a Wiki, SVN, etc. -- this frees us up to not have
>      to worry about the details of putting systems in place to handle
>      these things and I think we can safely bank on Google somewhat for
>      providing decent servers, backups, etc. for our hosting.
>
>      Currently William and myself are the dual owners, and we both have
>      executive power to make decisions about the library, so if one of
>      us disappears-- at least there is a backup.
>
>      Regarding the name change.  I've seen many people get confused over
>      JSON-RPC-Java versus the JSON-RPC protocol.  Given that
>      JSON-RPC-Java and jabsorb are evolving into something that may not
>      necessarily be completely tied to the JSON-RPC protocol anymore, it
>      makes sense to call it something else, both to avoid the confusion
>      and to more accurately reflect what it is.  We decided to call it
>      jabsorb -- it's not quite an acronym, although it could be thought
>      of as one (JAva BrowSer ORB.)  Indeed, JSON-RPC-Java already has
>      some of the ORB-like features that are not strictly part of
>      JSON-RPC ( e.g. Callable References, [1]et.al), and with Circular
>      References and a few other changes -- both the parent library and
>      the fork will diverge even more from strict JSON-RPC.
>
>      The name was designed primarily to be short and easy to remember
>      and pronounce.
>
>      You may have been referring more to a package name change, to
>      remove the com.metaparadigm corporate ownership?  Yes, that is an
>      important consideration too-- we wanted it to be something more of
>      a community driven entity, rather than from a .com corporate entity
>      which appeared to (whether true or not) have the commercial
>      interests of metaparadigm at the heart of the library.
>
>      In any case, I think the library needed both a package name change
>      and a library name change.
>      So, for the time being, we are going to continue with jabsorb
>      (especially since we have such a great start and good momentum now)
>      but we are certainly open to your suggestions, guidance and a
>      possible reunification in some form-- although, this would have to
>      meet certain requirements for the direction of the library, the
>      hosting situation, naming and control of basic things (which I
>      think were laid out pretty well in the project goals in the
>      original jabsorb release announcement and this message) to be done
>      successfully.
>      If you'd like to be a project member of jabsorb and give executive
>      guidance and even submit code changes if and when you have the
>      time, that would be great!  If it all works out, we could even just
>      say that jabsorb is a renaming and change of hosting setup/location
>      for JSON-RPC-Java... all that depends on you and your requirements.
>      I invite you, the jabsorb team, and anyone else who is interested
>      in the direction of the libraries to reply to this thread and
>      discuss all of these needs and issues as well as any that I have
>      not thought of, and I am optimistic that we can come to some
>      conclusion that everyone will be happy with.
>
>    On 9/23/07, Michael Clark <[2]michael at metaparadigm.com> wrote:
>
>      Hi Arthur,
>      Arthur Blake wrote:
>      > We are pleased to announce *jabsorb
>      <[3]http://code.google.com/p/jabsorb >*, a
>      > new Java to JavaScript JSON-RPC library!
>      >
>      > The project goal for *jabsorb* is to maintain (and hopefully
>      improve) the
>      > practicality and beautiful simplicity that makes
>      > JSON-RPC-Java<[4] http://oss.metaparadigm.com/jsonrpc/ >a great
>      library,
>      > while also adding new common sense features, more test
>      > cases, and more documentation to make the library better for
>      everyone.
>      >
>      Yes I have to admit I have been to busy the last year to spend much
>      time
>      on maintaining JSON-RPC-Java.
>      In any case I support this effort of maintaining and enhancing
>      JSON-RPC-Java and would in fact like these enhancements to be
>      imported
>      into the JSON-RPC-Java trunk for its next release.
>      If anyone would like to help please let me know and I can arrange
>      subversion access.
>      If we can avoid a fork I would prefer that. In some respect I would
>      support a renaming of the project to reflect it becoming a
>      community
>      effort. Nonetheless I would like to stay involved in this project
>      (or
>      more clearly the re-unification of this fork) as the present code
>      and
>      documentation that forms the basis or jabsorb was 80-90% authored
>      by myself.
>      Michael.
>
>      --~--~---------~--~----~------------~-------~--~----~
>      You received this message because you are subscribed to the Google
>      Groups "jabsorb-user" group.
>      To post to this group, send email to
>      [5]jabsorb-user at googlegroups.com
>      To unsubscribe from this group, send email to
>      [6]jabsorb-user-unsubscribe at googlegroups.com
>      For more options, visit this group at
>      [7]http://groups.google.com/group/jabsorb-user?hl=en
>      -~----------~----~----~----~------~----~------~--~---
>
> References
>
>    1. http://et.al/
>    2. mailto:michael at metaparadigm.com
>    3. http://code.google.com/p/jabsorb
>    4. http://oss.metaparadigm.com/jsonrpc/
>    5. mailto:jabsorb-user at googlegroups.com
>    6. mailto:jabsorb-user-unsubscribe at googlegroups.com
>    7. http://groups.google.com/group/jabsorb-user?hl=en
> _______________________________________________
> Json-rpc-java mailing list
> Json-rpc-java at oss.metaparadigm.com
> http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
>
>   




More information about the Json-rpc-java mailing list