Server-side code location

[Dane Gardner]

These are architecture thoughts that came to the surface while writing
the "licensing" post.

As per the SBIR submitted to NASA, we've got a client-server model
which will include server specific code. How are we integrating that
into the overall Open|SpeedShop project? From what I see, we have two
options.

1. We can have the code directly integrated into the main Open|
SpeedShop codebase. This would not allow for it to be separate
project code though, which may violate the SBIR agreement.

2. We have it as a separate install, which interacts with the Open|
SpeedShop libraries dynamically. However, this may require some
modifications to O|SS that wouldn't be officially funded by the SBIR --
how do we go about getting support for that? This option also makes
it more difficult to install for a sysadmin --at the very least it's
one more step. That being said, it does allow for a smaller install,
which is nearly always preferred.

I'm definitely leaning toward option two, but would this project be
supported by the Krell/O|SS side of things?

[JimG (jegkas-gmail)]

Hi,

I agree that this should be a separate install. I believe we can
cover the OSS modifications as part of OSS development improvement
funding.
That is my opinion, others may differ. When the CBTF project is at
the stage where we can reconstruct OSS from the CBTF components.
Those components will allow be separate configured and built
components.

Thanks,
Jim G

[Martin Schulz]

Hi all,

On Feb 22, 2011, at 10:57 AM, JimG (jegkas-gmail) wrote:

> Hi,
>
> I agree that this should be a separate install. I believe we can
> cover the OSS modifications as part of OSS development improvement
> funding.
> That is my opinion, others may differ. When the CBTF project is at
> the stage where we can reconstruct OSS from the CBTF components.
> Those components will allow be separate configured and built
> components.

Yes, I agree - I think the new GUI should be a CBTF component
that attaches to the data pipeline through a generic interface
(which I guess would be the CLI in one form or another). The
actual CLI client, done as part of the OASCR project, could then
be a second one - this would not only make things nicely
separated, but will also be a good proof of concept.

Martin

>
> Thanks,
> Jim G
>
> On Feb 21, 9:03 am, Dane Gardner <gard...@krellinst.org> wrote:
>> These are architecture thoughts that came to the surface while writing
>> the "licensing" post.
>>
>> As per the SBIR submitted to NASA, we've got a client-server model
>> which will include server specific code. How are we integrating that
>> into the overall Open|SpeedShop project? From what I see, we have two
>> options.
>>
>> 1. We can have the code directly integrated into the main Open|
>> SpeedShop codebase. This would not allow for it to be separate
>> project code though, which may violate the SBIR agreement.
>>
>> 2. We have it as a separate install, which interacts with the Open|
>> SpeedShop libraries dynamically. However, this may require some
>> modifications to O|SS that wouldn't be officially funded by the SBIR --
>> how do we go about getting support for that? This option also makes
>> it more difficult to install for a sysadmin --at the very least it's
>> one more step. That being said, it does allow for a smaller install,
>> which is nearly always preferred.
>>
>> I'm definitely leaning toward option two, but would this project be
>> supported by the Krell/O|SS side of things?
>

> --
> You received this message because you are subscribed to the Google Groups "Open|SpeedShop-GUI" group.
> To post to this group, send email to openspee...@googlegroups.com.
> To unsubscribe from this group, send email to openspeedshop-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/openspeedshop-gui?hl=en.
>

________________________________________________________________________
Martin Schulz, sch...@llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA