App stuff

[Ivan R. Judson]

Now that I've had time to read this and figure out what I think :-)

> >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.

Cool.
 
> >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?

I think we missed something here in email. I was probably not clear enough.
We can finish the discussion we started last week this week. Or continue in
email.
 
> >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.

Cool.
 
> >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.

I think you said exactly what I said to Tom at GGF and he gave me some
response that convinced me of what I said.  Perhaps he'll pipe in and say it
again.
 
> >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.

I've got a copy of the branch but have no mods. Feel free to work away.
 
> >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.

Well. I see your point, but I think there's some finicky work that is middle
ground for both of us.  What I mean is that we really don't want to be in
the business of building interface code, we've always avoided that. I'm
thinking of the use of CORBA we've made in the past for development very
similar to this. In the CORBA model we spent little time on the IDL and
refined it quickly by auto-generating interface and glueing it to
implementation and verifying it was was we wanted. We didn't really muck
with the internals of the corba interface, but we used it to accelerate our
understanding of the interface description and the underlying
implementation.  That's what I'm trying to describe when I say "we don't
want to build interface".  We definitely are in the business of defining the
interface and building the implementation, but the glue between feels like a
black hole that will steal cycles and then go away in 3 years (like CORBA
did :-|).

Does that make more sense? Is it less disagreeable?
 
> >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.

I agree at the "defining the interface" level, and I think I restated what I
meant much more clearly above. I hope so anyhow.
 
> >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.

I see the value in your point. But I'm wondering how it maps to what I
described above. Perhaps you can connect the dots (I'm not trying to be
sarcastic, email is just pathetically limited for espressiveness)?

--Ivan