[Antelope] Antelope Digest, Vol 8, Issue 3

[Michael Potter]

On Fri, Dec 19, 2008 at 10:00 AM, <antelope-request at brtt.net> wrote:

> Send Antelope mailing list submissions to
>        antelope at brtt.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://brtt.net/mailman/listinfo/antelope_brtt.net
> or, via email, send a message with subject or body 'help' to
>        antelope-request at brtt.net
>
> You can reach the person managing the list at
>        antelope-owner at brtt.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Antelope digest..."
>
>
> Today's Topics:
>
>   1. Re: Fwd: * newbie alert * (Hank Ratzesberger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 17 Dec 2008 16:44:33 -0800
> From: Hank Ratzesberger <hankr at crustal.ucsb.edu>
> Subject: Re: [Antelope] Fwd: * newbie alert *
> To: antelope-users at brtt.com
> Message-ID: <46413906-4EDF-47E2-BE3D-413E6B92577E at crustal.ucsb.edu>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> Michael,
>
> I don't know what replies you have received off-list, but
> there are actually many people on this list to whom
> I am grateful for the help I have received over the years,
> also having started from a blank page.


Only a couple so far, but yours is the longest yet! I hope once I start
posting specific questions more people will speak up.


>
>
> Even so, I agree that there are a myriad of options but
> not a lot of deployment examples. I also continue to
> wonder if I am doing things in the "usual way" or
> "the way we used to do it before feature X was ready" and
> so forth.
>
> I agree that we should develop some conventions and best
> practices and perhaps these can be agreed to or a public wiki
> opened up where they can be posted an commented on.


That would be an excellent idea. One thing about a distributed system like
antelope is that there are so many possible ways you could configure a
system, but I suspect in reality people choose from a smaller number of
well-proven patterns that are known to work through experience or just
intuition. It would be nice to be able to compare and contrast our system
architecture with others, just to know how wildly out of line or otherwise
our design is. One possible outcome of a wiki site could be a 'reference'
architecture for Antelope installations (or maybe several to cater for
different scenario's) that represents a kind of standard that most in the
community agree with - and would be a starting point for new system designs.



>
>
> In the mean time, I use these:
>
> o Always use the directory structure created by rtinit
> o If you want your database to have another name then, rtinit my-db-name
> o Run orb2db from the same system as the orb (localhost)
> o "Pull" data at the most stable system from field sites
>    i.e. orb2orb remote-field-site:6610 localhost:6610
>
> And I have a lot more if want.  Perhaps some on the
> list disagree with the above....


>From what I recall we are doing the second two. One specific thing I would
like to hear about is how people are running tests or validation suites,
both at a unit and integrated level. It seems quite hard to do this in a
quantitative, repeatable manner with components that are built to run in a
real-time system.


>
>
> Best,
> Hank


Cheers and thanks of for the response


>
>
>
>
> On Dec 12, 2008, at 11:59 AM, Michael Potter wrote:
>
> >
> > G'Day Folks,
> >
> > I am a recent entry into the world of Antelope, having recently
> > started work for the Australian Tsunami Warning System at
> > Geoscience Australia as a software engineer team lead. So far my
> > impressions is that working with Antelope will be both exciting and
> > interesting, if not a little daunting, which is partly why I have
> > introduced myself to this list, as I hope to connect with a network
> > of other Antelope users for support, guidance and advice. I am
> > particularly interested in best practices, standards and strategies
> > that the community has identified as being effective in building
> > stable, robust real-time systems that can be matured and changed
> > with confidence.
> >
> > Hope to be in touch with many of you soon
> >
> > Cheers
> > megamic
> >
> >
> >
> > _______________________________________________
> > Antelope mailing list
> > Antelope at brtt.net
> > http://brtt.net/mailman/listinfo/antelope_brtt.net
>
> Hank Ratzesberger
> NEES at UCSB
> Institute for Crustal Studies,
> University of California, Santa Barbara
> 805-893-8042
>
>
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Antelope mailing list
> Antelope at brtt.net
> http://brtt.net/mailman/listinfo/antelope_brtt.net
>
>
> End of Antelope Digest, Vol 8, Issue 3
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brtt.net/pipermail/antelope_brtt.net/attachments/20081219/4bf81aa3/attachment.html>