Thread: Re: [OpenSTA-devel] Alternate GUI for OpenSTA?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Corey,

Dan and I discussed this at length in Hebden Bridge and I believe that =
it
has to be the next big step!=20

I'd like to take a look at what you've done but so short of time it =
would be
really hard to fit it in...=20

So, when you say "dynamic" what do you mean? As in dynamic typing or
interpreted or just one that has an active community?

I think all your other motivations are good ones - open-source, well
supported language etc. As an example, Facilita have developed their
commercial tool's gui with Python.

I'd encourage choosing the language carefully, however. It should be =
based
on the best one for the task. If Python is the language then great! But =
it
shouldn't be based on familiarity...

So, what are the needs (IMHO)?=20
* Open source=20

* Popular (to encourage more developers to get involved)

* Cross-platform support (for obvious future motivations)

* Flexibility (i.e. Object Oriented, facilitating 'strangling' the =
existing
code (see http://www.martinfowler.com/bliki/StranglerApplication.html)=20

* Longevity of the language and community support

* Availability of libraries (e.g. CORBA library for test orchestration)

* Performance (for future extension of the core)

Do we want the core and GUI to be in different languages? Do we care? =
Dan
considered XML-RPC as a means of providing a GUI with interfacing to the
core... so, anyone could then write their own GUI in any language they
wanted. So, then XML-RPC / Web services support would become an issue in =
the
availability of libraries category.

Ideally, we'd weight each of the above categories, short-list some =
languages
(e.g. Python, Java, Ruby, C++) and score them. If that meant it was a
language most of us weren't familiar with, we could try to recruit a
developer who could act as the language expert on the project.

I'd also encourage looking at the Eclipse Test & Performance Tools =
Platform
Project (TPTP) http://www.eclipse.org/tptp/  as a potential platform =
that
may reduce some of the development overhead... eclipse is very pluggable =
so
a lot of the IDE and graphing features would already exist in the =
platform.

I'd encourage looking at the features we want and start - one by one -
implementing enough of the GUI, intermediate layers and Bridges (as in
Bridge Design Pattern) for the core to support each feature (i.e. using =
an
Agile approach).

JMHO

Antony
___________________________________________

e: 	ant...@et...
t:	+44 (0)845 056 8817
m:	+44 (0)795 628=A06228
w:	www.etest-associates.com
b:	am.testingReflections.com

etest associates (UK) ltd.
Kemp House
152-160 City Road
London
EC1V 2NX

___________________________________________
The contents of this message are intended for the addressees only and =
should
not be forwarded, copied or distributed in any medium without the =
permission
of the author. Any statements made in this message are solely the views =
of
the originator and do not necessarily represent the views of etest
associates (UK) limited. etest associates (UK) limited does not accept =
legal
responsibility for any statements or commitments made in this message.

> -----Original Message-----
> From: ope...@li... =
[mailto:opensta-devel-
> bo...@li...] On Behalf Of co...@go...
> Sent: 11 June 2006 05:33
> To: ope...@li...
> Subject: [OpenSTA-devel] Alternate GUI for OpenSTA?
>=20
> I have followed OpenSTA closely for a pretty long time and was =
involved in
> conversations on this list a few years back about the future =
development
> of
> OpenSTA.  We discussed lots of issues and possible future directions.
>=20
> Since then, no major shifts have happened and developer involvement =
seems
> to be
> ultra low.
>=20
> The GUI in OpenSTA is built using MFC and is showing its age.  Its
> editing, test
> setup, and execution are adequate.. but its monitoring, results =
analysis,
> and
> graphing abilites are far behind what proprietary rivals offer and are
> also
> very brittle.  Furthermore, the fact that its development environment =
is
> complex and proprietary may drive prospective contributors away.
>=20
> However, a strong point of OpenSTA is its fast and scalable load
> generating
> core.  This is accessible in a batch mode via the command line.
>=20
> info here:
> =
http://portal.opensta.org/modules.php?op=3Dmodload&name=3DphpWiki&file=3D=
index&p
> agename=3DOstaCommandLine
>=20
> some related utilities:
> http://www.trickytools.com/php/opensta.php
>=20
> For results reporting, OpenSTA also logs to csv files that you can
> process.  So
> basically OpenSTA's core can be driven without its existing GUI.. both
> execution and results analysis.
>=20
> As a proof of concept, I built a Python based framework for OpenSTA
> results
> analysis.  It parses timers, generates time series, runs calculations, =
and
> graphs results that come out of OpenSTA.
>=20
> I would like to post a document showing my results analysis module in
> Python.
> Would people be interested in seeing it?
>=20
> As a next step, a wrapper could be built around the CLI and a new GUI =
for
> test
> execution and management could be developed.  Eventually all UI =
modules
> couldbe
> con verted over, while leaving the core of OpenSTA in tact.
>=20
> As to why Python.. the goal I have in mind is to create a flexible =
open
> source
> UI written in a dynamic object oriented language that has a lot of
> existing
> module/library support, can integrate well with a C++ execution core, =
and
> can
> be developed using all Free tools.  Another reason is an eye towards
> future
> cross-platform compatibilty.
>=20
> Does anyone have any thoughts about this idea?  From what I can tell =
it
> seems
> very feasible.
>=20
> -Corey Goldberg
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=20
>=20
>=20
> _______________________________________________
> OpenSTA-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensta-devel