Re: Confluence for SoC

From: Andrus Adamchik (aadamchi..pache.org)
Date: Thu Jun 01 2006 - 22:12:57 EDT

  • Next message: Andrus Adamchik: "Re: Confluence for SoC"

    [forwarding our conversation with Marcel about the best use cases for
    Remote Object Persistence to the list]

    On Jun 1, 2006, at 8:28 PM, Marcel wrote:

    > I could probably write a Confluence plugin that makes a refreshPage
    > method available via XML-RPC or SOAP which would do the job, but we
    > are straying into 'when all you have is a hammer, every problem
    > looks like a nail' territory...Confluence has a fairly full-
    > featured RPC interface available which would be the logical choice
    > for implementing an editor like this. We are proposing workarounds
    > for what is really a very good system because our solution doesn't
    > match the target. I understand why - the aim of the project is to
    > get a good example app for Cayenne's ROP - but if we pursue this
    > path we are going to end up with something rather awkward which
    > won't make the feature look very attractive at all.
    >
    > My preference would be to move to a target which is better suited
    > to the tool at hand. Cayenne provides for direct DB interaction,
    > making 'loosely wrapped' applications (in the sense that one can
    > operate on the DB without having to crowbar in under the
    > application) a much more suitable target. Anything which is written
    > in an interpreted Web language - such as PHP or ASP - will be
    > amenable to editing via Cayenne ROP because all the data is stored
    > in the DB. Confluence seemed, prima facie, like a good target, but
    > it has (IMHO) turned out to be too sophisticated. Cayenne deals
    > with databases, not applications. I am not fussed what the target
    > is, but given that we have a hammer, it should be a nail. I can
    > think of a couple of targets off the top of my head - Joomla! open
    > source CMS, phpBB bulletin board - but I think it would be a good
    > idea to ask the dev list, or even the user list.

    All real life systems are sophisticated, I don't see this particular
    problem by itself as too bad to turn us away from the Confluence
    implementation. However I agree with the bigger point - if we are
    building something intended to be used as an example, we'd rather
    choose a good one. I am not psyched about an interface to a PHP CMS
    either - I am still to find a PHP user who'd agree to run Tomcat on
    their server.

     From my experience most systems that are using solutions similar to
    ROP (and early ROP adopters) are either client programs automating
    some business tasks, or applications that need to manipulate visual
    data in a way a web browser can't (think Java2D, picture management,
    maps, games and such).

    The simplest thing would be to do a fake app from the first category.
    The cool thing would be to do something from the second or a mix as
    it would demonstrate why a Java client is preferred to the web UI.

    Just recently I did a prototype for a client using Piccolo
    visualization framework [1]. It allows you to display object graphs,
    do zooming and panning and moving things around. So we can do a
    simple photo album application for instance.

    Let's brainstorm other ideas as well, but we need to do it quickly as
    the project time is limited.

    [1] http://www.cs.umd.edu/hcil/jazz/index.shtml
    [2] http://www.cs.umd.edu/hcil/jazz/applications/
    index.shtml#java_piccolo

    Andrus



    This archive was generated by hypermail 2.0.0 : Thu Jun 01 2006 - 22:13:22 EDT