Marcus Crafter wrote:
>>I was thinking about that as well. This should actually be very easy to
>>do. Most of the code
>>to store things into XML format is already in there. It is used to save
>>the instrument-manager state to disk.
>>
>>
>
> ok. I noticed that the .sampledata was stored in XML. Which code in
> particular formats the data into XML ?
>
There are saveState methods in the DefaultInstrumentManager,
InstrumentableProxy,
InstrumentProxy, and AbstractInstrumentSample classes.
> Currently I've put together a simple connector that can access the
> various samples currently being measured by the instrument
> manager. What I'm trying to work out how is how to publish this
> as an Axis service for example.
>
If you are controlling the lifecycle yourself, then there is nothing to
register. Just make sure
that your connector does not use the IM after it is disposed.
For now, keeping the connectors that the IM instantiates hidden was kind
of intentional.
I was thinking that the only connectors created by the IM would be for
internal use. Any
external connectors would just reference the IM through its normal API,
meaning that
the external connector can be any class at all.
>>I had been thinking though. Currently this is being done using
>>Configuration objects. But
>>if it is used more frequently, as it would be with SOAP. It might make
>>sense to get down
>>and dirty and write the XML directly to a string buffer or something to
>>avoid all of the
>>overhead. Not sure how much of a difference it would make though.
>>
>>
>
> Could be an improvement. I noticed Axis uses string buffers too in
> some places for creation of xml rather than sax/dom serializers.
> Once its up and running we could run it through some tools to
> check the 80/20 rule :)
>
>>I would also like to make a simple servlet based client. Basicly just a
>>WAR that could be dropped into any container and have it work.
>>
>>
>
> Do you mean a servlet based client like the swing one ? This is
> exactly what I want to do with Cocoon, as part of an admin app
> (as part of my project work here).
>
Yes, it would be simmilar to the current swing based client. Only you
would be able to
access it remotely via a web browser. Instrument sample data would be
available in
table or chart formats. The charts would be dynamically generated JPEGs
based on
the current charts. I can even use the current LineChart class to do so
without any
modifications. Did something very simmilar at my old job.
> Once the data is available in XML via SOAP for example it will be
> very easy to build up a great looking application with SVG charts,
> graphs, etc.
>
SVGs would be more light weight, than JPEGs which is always good.
>>You look like you have been using the Swing client for a bit now.
>>Anything that you would like to see improved?
>>I have a list in my head already. :-)
>>
>>
> I have only been using the swing client recently - it looks quite
> nice though, well done. Whats in your list of improvements? :)
>
Lets see...
List of things that I still need to get done in the Instrument Client
1) DOCUMENTATION!! for all 3 instrument projects.
2) Add a new layout mode which places all visible charts into
a grid rather than an MDI interface. Laying them out is a pain.
The save state feature helps a lot though.
3) Improve the Create Sample dialog so that it does a better
job of creating default names.
4) Implement the Start Maintaining Lease dialog so that you can
specify everything settable in the Create Sample dialog.
5) Add an optional IM to the client (mainly for debugging the
client) It would also show things like the number of sample
snapshots downloaded etc. Give you an idea of how much you are
loading down the server. That could also be added to the
instrument-manager Instrumentable though.
6) Add a new list, still thinking about where, which shows all
of the samples. Samples can be difficult to find in the
current tree if there are a lot of Instruments.
7) Get the old menu working again so the tree can be hidden to
save space.
8) Figure out a couple of altrmi oddities (probably the
client's fault). If you leave the client running while
stopping and starting the server several times, you will
sometimes get errors in one or the other's console. Altrmi
also has a timeout where it keeps trying to reconnect to the
server for a while before finally giving up...
9) Localization. I want to extract everything into resource
files so that the interface can be localized.
10) Add ability to set the interval at which sample snapshots
are requested.
11) Maybe add the ability to receive logger output? Unrelated.
I will place this list in a todo in the client's root. Anything else
that you would like to see?
Cheers,
Leif
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
