embedlets-developer

[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

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

[James C. <ca...@vi...>]

>But seriously, why do you think I've been stressing the
>availability of a "connector embedlet"

Thats all I really mean't just to be sure that it is 'visible' in the right
place from the beginning.

>As for creating C# implementations <snip>

I wasn't suggesting we do this in C# only that .NET is going to linger and
cross pollinate with Java so we should be ready for it.

James Caska
http://www.muvium.com
'Java Bred for Embedded'




> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Wednesday, January 29, 2003 9:42 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: .NET, "dead" XML configs,
> Schemas/DTDs, and catchups....
>
>
> 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
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>