[Building Sakai] Any Comments on org.codehaus.jackson ??

Thu Jun 20 07:42:40 PDT 2013

I think that the way entitybroker works (distributed entities) is a good
pattern.

I've also been very pro versioning but there was never a great time, I
think Keitai makes this a good time. I've had this ticket open for over a
year (what Aaron describes) that should only involve adding a new method to
the interface (but would break every existing entity, which is why we held
off) : https://jira.sakaiproject.org/browse/SAK-21959

If the performance can be improved by using standardized libraries (faster
json/xml encoding, etc) that sounds like good improvements. There's code in
Sakai core that actually generates json and xml with StringBuilder or some
type of other custom string concatenation. :/

On Thu, Jun 20, 2013 at 9:08 AM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> Wow, touchy much?
>
> I was actually responding to a previous comment questioning whether EB was
> the best fit for REST overall, since Jackson/Jersey/REST/EB, you know, its
> all related.
>
> I also said that I plan on looking at the performance of EB, the current
> provider for REST in Sakai, and obviously will contribute anything that is
> developed there back to the main code. If you really want to get into it, a
> number of enhancements relating to XML generation in EB were suggested to
> you 12 months ago that would make it the elements better defined and more
> compliant with expected XML generation, and be a huge improvement for
> external tools wanting to integrate with Sakai. And that went nowhere. So
> if you want to discuss those issues and the merits of what REST should be
> in Sakai, then lets get this on a new thread.
>
> It's interesting that whenever anyone suggests possible improvements or
> modifications in this community it almost always gets a negative response
> about resourcing. I can cite many examples. It's almost like a discussion
> can't actually be had on anything because unless the proposer is going to
> be the one doing it, then you shouldn't even bring it up. Hardly
> encouraging for open discussion that someone might see and actually invest
> in...
>
>
>
> On 20/06/2013, at 10:46 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>
> >> Though it has been mentioned before that the providers should be
> versioned
> >> like an API, so maybe they should all be in the one webapp?
> >
> > Putting all providers under one webapp is a non-starter in my opinion.
> > The entire point of EB was to distribute out control over endpoints
> > (and entity management) to the various parts of the system (without
> > causing classloader issues) and still have them all documented and
> > under a central path (/direct). You would make it virtually impossible
> > for contrib tools to make endpoints and I would consider this a major
> > step backwards and I would -1 it if it were proposed.
> >
> > Versioning could be handled without an overbearing change like that.
> > /direct/1.1/thing/... where ... is the rest of the typical path.
> > Leaving off the version number (like it is today) could simply use
> > whatever the highest version is to avoid breaking the contract for all
> > the apps out there.
> >
> > That said, if you (or anyone) can find a way to put in some other
> > mechanism and still be backwards compatible (and of course agree to
> > maintain that change) then please feel free to make a branch and get
> > to coding. I certainly welcome any improvements that do not break the
> > current API contracts and don't degrade performance significantly.
> >
> > However, I think you should stop hijacking this thread and start a new
> > one if you want to continue to discuss this.
> > -AZ
> >
> >
> > On Thu, Jun 20, 2013 at 8:25 AM, Steve Swinsburg
> > <steve.swinsburg at gmail.com> wrote:
> >> It would actually be pretty trivial to move all of the EB entity
> providers
> >> over to a servlet style setup, map on the same paths using Jersey and
> keep
> >> the same input and output config. Though we also need to honour the
> other
> >> capabilities that can be performed through EB that may not have
> equivalents,
> >> but not impossible.
> >>
> >> The nontrivial part would be wiring up registration code so that
> separate
> >> 'providers' in the various webapps could all participate under /direct.
> >> Though it has been mentioned before that the providers should be
> versioned
> >> like an API, so maybe they should all be in the one webapp?
> >>
> >> I do like EB, but its possible to do what it does in other ways for
> sure.
> >> Part of Project Keitai will actually be looking at the performance of
> Entity
> >> Broker so this is a very timely discussion to be had.
> >>
> >> cheers,
> >> Steve
> >>
> >>
> >> On 20/06/2013, at 8:55 PM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
> >>
> >> Scalatra uses Jackson for its JSON support.
> >>
> >> http://www.scalatra.org/guides/formats/json.html
> >>
> >> I wonder whether it's worth at some point discussing whether EB as it
> stands
> >> is a good fit for actually mapping REST paths onto functionality?
> >> ActionsExecutable does a RESTlet type job in that you can pick out path
> >> components but in the end you just end up with an entity provider with
> one
> >> big executable action and some private methods for handling the incoming
> >> paths. What I'd like to do is just map paths onto handlers without
> >> repeatedly writing path parsing boilerplate.
> >>
> >> EB does a good job and fills a gap, but it has to be maintained so it's
> >> perhaps worth considering whether we can use a more broadly used REST
> (and
> >> JSON) framework.
> >>
> >> Cheers,
> >> Adrian.
> >>
> >>
> >> On 20 June 2013 00:27, Steve Swinsburg <steve.swinsburg at gmail.com>
> wrote:
> >>>
> >>> Here's another perf comparison
> >>>
> >>>
> >>>
> http://blog.novoj.net/2012/02/05/json-java-parsers-generators-microbenchmark/
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On 20/06/2013, at 2:30, "Zach A. Thomas" <zach.thomas at gmail.com>
> wrote:
> >>>
> >>> On the performance question, I have referred to this benchmark in the
> >>> past:
> >>> https://github.com/eishay/jvm-serializers/wiki
> >>>
> >>> As for other options, can you recommend an alternative?
> >>>
> >>> Zach
> >>> On Jun 19, 2013, at 10:33 AM, Aaron Zeckoski <azeckoski at unicon.net>
> wrote:
> >>>
> >>> 1) Jackson is the best/fastest JSON reader/writer and Object/JSON
> mapper.
> >>> I would love to see us standardize on this. I am using in my own
> >>> EntityProviders for output.
> >>>
> >>>
> >>> That's an opinion I strongly disagree with so I would not be a fan of
> >>> us standardizing on this at all. I would like to see some strong
> >>> evidence to backup this statement. I attempted to use this for JSON
> >>> handling in multiple projects and we settled on other options in every
> >>> case (re: matterhorn, dspace, EB, etc.). The handling of maps and
> >>> collections was especially problematic (at the time anyway).
> >>>
> >>>
> >>> _______________________________________________
> >>> sakai-dev mailing list
> >>> sakai-dev at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >>>
> >>> TO UNSUBSCRIBE: send email to
> >>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> >>> "unsubscribe"
> >>>
> >>>
> >>> _______________________________________________
> >>> sakai-dev mailing list
> >>> sakai-dev at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >>>
> >>> TO UNSUBSCRIBE: send email to
> >>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> >>> "unsubscribe"
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> sakai-dev mailing list
> >> sakai-dev at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >>
> >> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org
> >> with a subject of "unsubscribe"
> >
> >
> >
> > --
> > Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130620/962b56f6/attachment.html 