[Xastir-dev] Topic: Supported Platforms, Xastir-NG

[Tom Russo]

On Mon, Jun 16, 2008 at 10:17:41AM -0700, we recorded a bogon-computron collision of the <archer at eskimo.com> flavor, containing:
> 
> Here are the tendencies in this thread so far:
> 
> 
> *) OO Design using UML (Unified Modeling Language), at least to the
>    class and method level.
> 
>    Examples of UML tools:  bouml, argouml, eclipse, Oxygen, Dia.
> 
>    Tom: Must we all use the same UML tools?

I can't answer that, but I'm thinking it'd probably be best.  That way we 
can have a single format for the saved project files, and all be able to
work on them in a configuration-managed way (CVS, SVN, or whatever).  Also,
the different tools will produce something different if used to generate
code.

It's not clear how many folks really need to be working in the UML tool,
unless we use it for long-term product development (which I don't think 
is ideal).  Perhaps there could be only a small handful of those tinkering
with the design artifacts directly, with input from the whole team?
I doubt everyone's going to want to have to learn the tools.

> ---------------------------------------------------------------------
> 
> Language choice & supported platforms can wait until the UML design
> well under way, but here are the tendencies along those lines:
> 
> *) C++ with STL.  Use only ANSI class libraries (no vendor-specific
>    class libraries).

I'd like to agree with the very reasonable suggestion of adding some 
dependence on BOOST (which is not vendor-specific, and is very portable).
Several of Boost's features (for example, reference-counted pointers)
are things that we should definitely have on our radar.

> *) C libraries only where necessary, using C++ wrappers.
> 
> *) C++, Python, Java, and Ruby bindings for the client API.
> 
> *) Less dependence on external libraries, to control reliability/
>    quality/maintainability.

Dependence on moving-target APIs like ImageMagick and Berkeley DB has been
probably the most irritating issue with keeping Xastir working. 

> *) Add a layer between the daemon and the database, to keep as much
>    database-agnostic as possible.

I would like to suggest that we back away at this early stage from a 
commitment to a client/server design decision, until such time as requirements
and use cases point to it as the clear implementation path.  I'm not 
convinced yet.  It might in the end seem more practical to make more of a
framework for constructing APRS applications rather than the daemon/client
model that some are assuming.  For example, it might emerge from the
groundwork discussions that it would be more reasonable to develop a class
library that provides the core (non-UI) functionality of an APRS application
that can be *used* by an application rather than depend on the communication
required for the client/server model.  Or the requirements really might
show that client/server is the right model.

Also, "add a layer between the daemon and the database" isn't exactly how
I'd phrase it.  I'd prefer to think of it as "encapsulating implementation
details of the database."   

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
 "It's so simple to be wise: just think of something stupid to say and
  then don't say it."  --- Sam Levinson