App stuff

[Robert Olson]

At 09:32 AM 3/13/2003 -0600, Ivan R. Judson wrote:

>Rather than block on this much longer since I think we want it soon; I'm
>sending yo u my issues to think about. Then you can respond perhaps with
>some proposed solution.  I can propose solutions too, however they're less
>likely to suit your taste than one you produce :-).
>
>First, simple thing: I think the Application Service wants to be an
>Application Factory. That's the pattern it implements. It's more clear to
>developers that way and it's not user exposed. It's to our advantage to
>leverage the clarity of common naming I think.

That's fine.

>Second, I'd like to minimize the design to keep things simple. The web
>service interface should only have 4 methods (and two of those I'd like to
>consider dropping) for join/leave (the two I don't think we _need_, although
>they are convenient), and get/set data.  I don't think we need to support
>more complex interactions until we are asked to do so.  Let's see what
>people build first.

Why shouldn't it have the data channel interface and state querying interfaces?

>Third, I'd like to encapsulate the client stuff in a class so the developer
>doesn't have to deal with the guts. It also affords us an opportunity to
>keep our decision about whether the app is a venueclient or not behind a
>clean interface so we can change our minds if we choose too.

That's fine; I think we need to well-document the protocol used in that 
client object so that one could write an application in something other 
than python.

>Fourth, I think I want to change our minds now on the venue client issue.
>I'm not adamant about it, but I think it's not advantageous to make all
>applications venue clients. They really aren't in a lot of ways and it feels
>like it muddy's our design to do that.

I don't feel strongly about it either way; we need to clarify the access 
rules on the venue, however. The current setup uses a venue client to have 
access to the list of applications in the venue.

>Anyhow, those are my four main concerns.  If we can blow through this today
>and get a timeline for merging the branch that'd be great.  I'm guessing it
>won't be for tomorrow, but perhaps it could be.

I've been avoiding doing anything with that branch as I'm assuming you or 
Tom have state on your machines, as I've not seen any checkins on it since 
you were working on the apps.

>Finally, We've gone back and forth on implementation vs interface, and I
>think it's clear (but easily forgotten) that we're building implementation.

Ah, I have to disagree strongly here. My understanding is that we're 
building a system based on web services, which will use web services to 
expose the interfaces to the system services. As such, if we want anyone 
else to be able to use the system, we need to have very well-defined and 
documented interfaces. The way to achieve that is to design the interfaces 
first, and implement to the interfaces.

>We're only building interface where it's missing. We're really relying on
>pyGlobus (and later pyGridWare) for interface.

I don't understand what you mean here; we're building interface each time 
we define a web service that might be used by a third party.

By a third party I mean, for instance, a C++-based client that is built 
with gSOAP, or a java-based portal that needs to access venue data via the 
java CoG kit.

>that being said, I don't
>think we need to explicitly build interface objects for all our
>implementation objects where they are only passing through with no added
>value.

The added value is the exporting of the interfaces via the hosting.pyGlobus 
interface; if we change to a different mechanism the implementation code 
can stay the same with new interfaces attached.

--bob