[Embedlets-developer] Re: .NET, "dead" XML configs, Schemas/DTDs, and catchups....

[Andrzej J. T. <an...@ch...>]

James is concerned:

> The point is that we certainly should ensure our embedlet specification is
> able to work with .NET at some point along the chain and we should design
> for it if possible or is this simply an outrageous thing to say to a bunch
> of java die hards!

.NET?  What's that?  Hasn't M$ dropped the .NET moniker?  Lord knows what 
they will call it next...hey, that might be it:  from: OLE to COM to COM+ to 
DCOM to .NET to .NEXT?  ;-)

But seriously, why do you think I've been stressing the availability of a 
"connector embedlet" that will use XML/SOAP to communicate to back end 
systems using Web Services?  That approach means we'll be able to integrate 
embedlets running inside the Outpost container to J2EE, .NET and any other 
Web Services-enabled back end system....targetting the maximum amount of 
integration capability.

As for creating C# implementations,  I see little value to that in the short term 
(aJile/Systronix are not likely to support C# on their platforms too soon).  Let's 
get a Java version running first.  Then a Java <--> C#  bytecode translator 
might be an easy way to accomplish this, if there is a demand.  Or just re-
implement Outpost as Outpost# (if someone cares to do such).

Brill then comments:

> IMO, this is the key to this system... setting it up "dead" would be fairly
> easy to do and doesn't bring any unique aspect.... which would put up my "So
> What?" radar.

Almost every other container system out there does it this way.....XML config 
files rather than serialized instances.  It's considered a "best practice" for a 
reason.  Just because it's not unique and "gee whiz" does not mean we 
shouldn't use it.  The goal of Outpost is very practical in nature.....so "gee 
whiz" stuff should be left behind, unless it clearly advances the goals.  When 
building a Container/Component system, there are many things that have to 
be specified that really don't belong inside the component instance object (and 
hence it's serialized form).

Jac doesn't like schemas:

> Having to know XML is not too much of a problem. Most people are able to 
> learn XML. The problem with XML is the DTD, how many XML documents are you 
> working on and how many DTD do you need to know to be able to create 
> correct XML documents?

You don't need a schema to use XML.  Validation for configuration files is not 
all that valuable, and even if it will add some limited value, the validation and 
schemas can be added after the fact quite easily, inferring these from the XML 
tags themselves.  The config file structure should be quite intuitive....probably 
modeled on servlet descriptors to some degree, just for familiarity reasons.

> Having even a simple application available to create a valid configuration 
> is very valuable IMHO. A wiring tool would be great!

Yup....that would be a real nice to have for sure!

Ted plays catchup:

> t took me 5 solid hours to read through and absorb all the traffic that you
> guys generated (sheesh, was it a full moon or something!?) and there were a
> significant number of absolutely critical ideas that were submitted.

Nope...been meaning to post some stuff and finally got around to it.  Will be 
posting some Container design ideas very shortly too....so we can start settling 
that down a bit to the point where I can start slinging some initial code.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com