Re: Confluence for SoC

From: Marcel (emmpeege..mail.com)
Date: Fri Jun 02 2006 - 02:15:06 EDT

  • Next message: Marcel (JIRA): "[JIRA] Created: (CAY-561) cayenne-rop: initial submission of code v2"

    Good point regarding running Tomcat on a PHP server - not a realistic
    scenario for most sites.

    How about a program which displays a graph of the objects that Cayenne
    has mapped, and browsing and editing of values? I guess that could be
    done with regular Cayenne, but given that Cayenne's ROP is easy to
    deploy (just add an ant task to build the classes into a WAR and then
    deploy it to Tomcat) it might be a useful tool for developers using
    Cayenne in web applications. After mapping the database, a Cayenne
    developer would then be able to browse the objects and their contents,
    and edit the database at an object level. It seems achievable, unless
    I'm missing a major complexity issue, and it is Cayenne focused. It
    would seem to be a useful tool on its own, and at some point it could be
    incorporated into CM if it moved to RCP. ROP functionality could be
    switched on and off without difficulty, it is simply a matter of getting
    the context from a different source. To me, that is the greatest
    advantage of Cayenne ROP - a third tier can be introduced almost
    completely transparently from the client's perspective. This kind of
    application would emphasise that.

    Another possibility is to provide a powerful viewing perspective on a
    web app such as Confluence - for example, a navigator that can provide a
    view(s) of the wiki unachievable via the Web. What those views might be
    is an open question, but one idea is Craig's node navigator, similar to
    the CNET news map ('The Big Picture') [1]. Editing could be introduced
    using Confluence's RPC interface (the nice way to edit pages ;) ), but
    that could take a little bit of time (ie I'm not sure how that will go
    with the Aug 21 deadline - not saying it can't be done, just that there
    is doubt). Alternatively it could load editing pages in a browser
    (internal or external). That would emphasise the other advantage of ROP,
    as a way to supplement a Web interface.

    I am more than happy to implement an application using ROP simply for
    example's sake, or to continue and hack around Confluence, but if we can
    come up with a 'proper' application of ROP that would be greatly
    preferable IMO.

    Marcel

    [1] eg:
    http://news.com.com/Report+Micron%2C+Hynix+e-mails+point+to+price-fix+scheme/2100-1006_3-6078970.html?tag=cd.top

    Andrus Adamchik wrote:
    > [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 : Fri Jun 02 2006 - 02:15:40 EDT