embedlets-developer Mailing List for Outpost Embedlet Container (Page 18)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrzej T. <an...@ch...> - 2003-03-13 21:31:13
|
> This is kinda' "cool"... you can now access for forums via. NNTP. > Might be a better way to communicate instead of filling up everyone's > mailbox. > > Are folks inclined to give it a try? Probably not....only because I receive the list in digest mode once per day (if that), which I find is very convenient for the way I work. I receive an automatic email without having to do anything or give it any though...rather having to remember to go and poll a newsgroup every once in a while. But it is cool. ....Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-03-13 03:11:43
|
This is kinda' "cool"... you can now access for forums via. NNTP. Might be a better way to communicate instead of filling up everyone's mailbox. Are folks inclined to give it a try? - Brill Pappin |
|
From: Ted K. <tk...@ya...> - 2003-03-12 22:58:16
|
Nicola said: > Java MIDP Game Developers Can Start Playing With Nintendo Game Boys > > >http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/03-06-2003/0001903263&EDATE= > http://www.jamid.com/ I was not even aware that Ajile was working on this. I wonder if these cartridges could be plugged into other devices besides a Game Boy (like a TStik)? Ted __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-03-12 17:05:01
|
Java MIDP Game Developers Can Start Playing With Nintendo Game Boys http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/03-06-2003/0001903263&EDATE= http://www.jamid.com/ -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Andrzej T. <an...@ch...> - 2003-03-12 00:56:45
|
Ted asks: > I know this is somewhat of an esoteric idea which probably does not have a > practical use but the thought that occurred to me was that if an Embedlet > container could be implemented practically anywhere, was it possible for one to > be implemented inside of an Embedlet (not by extending org.embedlet.Container > itself but by containing an object that did)? Aside from whether it is > reasonable or not, is it possible? It should be possible. In fact, I thought that something similar might be useful at some point. That is, running an Embedlet container inside a Servlet. ....Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-03-10 11:12:16
|
> Just for a lark (since Brill is being lax on getting some real devices > JAPL'ed <grins> and cause I don't have any devices to interface to my > TINI/JStamp/SaJe boards) I figured I would take a bit of time today and see > if the Chaeron open source GPS library will run in the current Outpost > container implementation. I'm in debugging now ;) Maybe I can create a peripheral for your GPS lib... which reminds me... what "peripheral" devices do people have to test with? I mostly use I2C, so there are a few I2C drivers already (most of the Devantech hardware). - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Ted K. <tk...@ya...> - 2003-03-10 06:50:49
|
Andrzej, > > > 3) Looking at the org.embedlet.container class the following question > occurred > > to me: Will Embedlets be able to contain Embedlets? > > Nope! An embedlet has to extend the org.embedlet.Embedlet abstract class > (which in turn extends org.embedlet.Component). An Embedlet is a component, > which lives in and is managed by an Embedlet-compliant Container. An > Embedlet does not extend org.embedlet.Container which it would have to do to > contain other components (which doesn't make much sense). Only Outpost > extends the Container contract. I know this is somewhat of an esoteric idea which probably does not have a practical use but the thought that occurred to me was that if an Embedlet container could be implemented practically anywhere, was it possible for one to be implemented inside of an Embedlet (not by extending org.embedlet.Container itself but by containing an object that did)? Aside from whether it is reasonable or not, is it possible? Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-10 03:53:11
|
Hi all: Just posted the next release versions in the releases CVS directory as follows: embedlet_004.zip outpost_004.zip outhouse_002.zip New features include: - ContainerEnabled & ComponentEnabled interfaces (for Chris) - Timer Service is now operational - Synchronous Event sending now supported - aJile and TINI builds for the Outhouse sample application - Lots more....check out the history.html file for details. - Check out the devnotes.txt files if you plan to make any mods. I have also populated the CVS repository with the source code, in three new modules, called: embedlet, outpost and outhouse respectively. Since these three "pieces" are independent of each other from a source perspective (though Outpost does need embedlet.jar, and Outhouse needs embedlet.jar and outhouse.jar), I decided to keep the source trees in separate modules, to allow for better parallel development of the Embedlet Spec, Outpost Container RI and Outhouse sample application. All the source files (java source, ant XML scripts, readme's, etc.) are now under source code control, as I had promised to do before the weekend was out. This initial population of the CVS repository has been tagged with the tag "Initial", as have the three new release zip files above (since they correspond with the initially populated source code base). All those list members that are authorized "developers" on the project can now check out, modify and check back in revised versions of the source code. Since Jalopy is not yet up to the task of enforcing our coding standards, please make a special effort to conform to the posted standards when making any modifications to the source code base. Please also create/include JUnit test cases for any significant new functionality that you add, so that we can ensure that the Embedlet "product" is always of the highest quality standard. I'm off to Hartford, CT tomorrow night, and with my laptop not yet repaired (waiting for an LCD replacement part which is not in stock yet), my posts may be rather infrequent till next weekend, though I may get webmail access at some point. What that means, in real terms, is that I'll stop monopolizing the list, and let some other people run with things for a while. <grins> Remember.....the more feedback/suggestions/questions that you post, the better the Embedlet spec, Outpost RI and Outhouse sample application will be in the long run. Enjoy the new stuff. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-10 03:40:22
|
Chris: > Hmmm, my documentation on J2EE says that there is an interface above > HTTPServlet - Servlet! Damned if you aren't correct. Sorry 'bout that. My Servlet docs never mentioned it. > I was in no way suggesting the contract be varied or violated... just that the > abstract implementation at the top level may need to accommodate platform or > optimization specific variations within the contract. Phew! Glad to hear that we are on the same page with this one! The primary purpose of my post was to make sure that everyone else understood the reasons for this.....I kinda figured that you understood it, and was right on that score. > Interfaces are the 'official' enforcers of an API contract not abstract > classes or specifications for that matter. Abstract classes can do ths same, but it's a moot point..... > Abstract classes are actually less formal in their contract enforcement > because one can extend them, write code to use the extension, plug it into the > container and only find out at run time that someone else's Embedlet does not > implement the extension or someone else's container does not call that method. Well...from that perspective, interfaces can be extended as well. If someone wants to contravene the "contract" there are always ways. But it won't be "standard". In any case, I have added to high level interfaces: ComponentEnabled and ContainerEnabled, and made the org.embedlet.Component and org.embedlet.Container classes implement these two core interfaces, as you have suggested. This is now in the newly posted release (announcement on this in another email). I didn't rename the abstract classes GenericXXXXX, mainly because it would require changes in a lot of other code, and the Generic designator does not add to the readability of the rest of the code. Just like with servlets, no-one typically casts to the Interface, since it is intended as an internal container implementation interface, no-one should typically be casting to the ContainerEnabled or ContainerEnabled interfaces either. Hope this meets with your approval.... > All good things and in line with your (and mine) draconian contract > adherence. Yup.... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-10 03:40:20
|
Ted: > Here are a few questions that came up as I have been looking through the > release 003 code: Too bad version 0.04 just got posted. <grins> > 1) In the core Embedlet build.xml file, if the 'compile' target depends on > > the 'init' target, why are the 'build.dir' and 'build.classes' > directories being made in both of these targets? Compile didn't used to depend on init, so it's just a historical artifact is all. If you try to create a directory in Ant that already exists, nothing happens, so it's not a big deal. > 2) The org.embedlet.Adapter class's Javadoc page states that 'The Adapter > class is the base class for all Embedlets'. Should 'Embedlets' here be > 'Adapters'? Yes. I fixed that and posted a new version to the CVS source tree. It is NOT fixed in the 0.04 release zip file. That's what happens when you copy/paste files sometimes. ;-) > 3) Looking at the org.embedlet.container class the following question occurred > to me: Will Embedlets be able to contain Embedlets? Nope! An embedlet has to extend the org.embedlet.Embedlet abstract class (which in turn extends org.embedlet.Component). An Embedlet is a component, which lives in and is managed by an Embedlet-compliant Container. An Embedlet does not extend org.embedlet.Container which it would have to do to contain other components (which doesn't make much sense). Only Outpost extends the Container contract. Hope this helps! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-10 03:40:16
|
Ted: > I am currently studying all of the classes in the core embedlets package and > my next step is to start looking through the Outpost and Outhouse code. Before you go down that road much farther, go and download the new versions I just posted! Details in a different announcement email.... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-09 19:29:50
|
Andrzej, Here are a few questions that came up as I have been looking through the release 003 code: 1) In the core Embedlet build.xml file, if the 'compile' target depends on the 'init' target, why are the 'build.dir' and 'build.classes' directories being made in both of these targets? 2) The org.embedlet.Adapter class's Javadoc page states that 'The Adapter class is the base class for all Embedlets'. Should 'Embedlets' here be 'Adapters'? 3) Looking at the org.embedlet.container class the following question occurred to me: Will Embedlets be able to contain Embedlets? Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Ted K. <tk...@ya...> - 2003-03-09 02:14:27
|
Andrzej, >Nice to know that my GPS Library code will also run on a TINI now too! > >I'm impressed! Are you impressed? <grins> I know I'll be impressed as soon as I can figure out exactly what you guys have put together! You and Chris and Gregg all have years of experience building event based embedded systems out in industry and it appears that Brill and James have a significant amount of experience in this area too. My strategy right now is to play with and study the code so that I can get everything solid in my mind. Yesterday I finished picking apart the Ant build.xml files and so I am now comfortable with what these are doing. I am currently studying all of the classes in the core embedlets package and my next step is to start looking through the Outpost and Outhouse code. Right now I am not in a good position to provide much useful feedback because I have very little to compare what I am looking at against. I think, however, this will change as soon as I start putting together some Embedlet based applications. I am estimating that it will take me another week of looking through the code in order to get a handle on it and then another week to start putting together some applications. Anyway, its great to hear that your GPS Library code runs in an Embedlet container because it is a real world application! I remember that at the first JavaOne conference I went to in 1999 they had a number of companies demonstrating their EJB containers running a test application. Some day it would be nice to see a similar thing happen with Embedlet containers running on a dozen or so embedded systems. Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Christopher S. <cs...@oo...> - 2003-03-08 23:41:12
|
___________
>
> Chris inquires
>
> > On the class hierachy:
> >
> > Is there a reason you have not used interfaces as the starting
> point for the
> > abstract classes? This requires an extra class(interface) but
> it provides a
> > huge amount of flexibility if we need to substitute versions
> (full/lite) or
> > platform specific implementations later.
> >
> > As you know it would be a simple level to add at the top:
> >
> > iComponent
> > ^
> > :__ Component
> > ^
> > |____ Embedlet
>
> This was very deliberate on my part.
>
> It would be simple to add, and could be done later if needed, without any
> impact on derived classes, but doesn't add much flexibilty or
> value at the
> moment (and has a cost). Let me explain my thinking on that....
>
> The Component method implementations only depend on other core
> specifications/interfaces (and no other implementation-dependent
> pieces).
> That is to say, Component uses stuff from LifecycleEnabled,
> EventConsumer and
> Properties, all of which are a mandatory part of the Embedlet
> standard, and
> has nothing in it that is or should ever be platform specific.
>
> The only class that would ever need to implement the ComponentEnabled
> interface (regarding naming conventions, I have used XXXXEnabled for
> interfaces.....LifecycleEnabled, PropertiesEnabled, etc, so would call it
> ComponentEnabled) is the Component abstract class. There should
> be no reason
> to have to implement that interface anywhere else, since managed
> components
> must extend (right now) Embedlet, Service or Adapter (which in
> turn extend
> Component).
>
> Component, as an abstract class, provides the interface definition
> intrinsically (abstract methods) along with default/mandatory/convenience
> method implementations that all components will typically need or have to
> have (eg. setContext() ).
>
> Servlets are designed this way....there is no "iServlet"
> interface....just
> abstract base classes (GenericServlet and HTTPServlet).
Hmmm, my documentation on J2EE says that there is an interface above
HTTPServlet - Servlet!
javax.servlet.http
Class HttpServlet
java.lang.Object
|
+--javax.servlet.GenericServlet
|
+--javax.servlet.http.HttpServlet
All Implemented Interfaces:
java.io.Serializable, Servlet, ServletConfig
If we were following the servlet model it would be:
Component (interface)
^
:___ GenericComponent (abstract)
|
+---- Embedlet (abstract)
|
+---- MyEmbedlet (concrete)
J2EE and most of the formalized container specs that I have seen follow this
design pattern. That is the reason for the (not so) innocent question ;-}.
> There is a fine line with Java best practices on when you use an
> interface
> and when to use abstract base classes. I'm basically following those
> practices here, since the Interface would add nothing in this particular
> scenario.
>
> Adding the interface can also cause method invocations to go through one
> extra redirection during invocation in many JVMs which will impact
> performance on contstrained platforms like the TINI.
>
> > if we need to substitute versions (full/lite)
>
> NO....NO....NO....EMPHATICALLY NO! <grins>
>
I second that NO...
I was in no way suggesting the contract be varied or violated... just that
the abstract implementation at the top level may need to accommodate
platform or optimization specific variations within the contract.
With an interface the contract is enforced but all abstract classes can be
substituted. This is the basis (to extreme lengths perhaps) for EJB
flexibility.
With an abstract class as the root you are stuck forever with the overhead
or perhaps even bugs of that class. This limits vendors (or ourselves) from
coming up with a better mousetrap while still living within the contract...
an impediment to acceptance.
Interfaces are the 'official' enforcers of an API contract not abstract
classes or specifications for that matter.
Abstract classes are actually less formal in their contract enforcement
because one can extend them, write code to use the extension, plug it into
the container and only find out at run time that someone else's Embedlet
does not implement the extension or someone else's container does not call
that method.
With interfaces the extensions are always defined in new interfaces to
maintain backwards compatibility. That way the container has a mechanism to
check e.g.. isAssignableFrom(EmbedletII).
As for overhead, interfaces do not have any because the contract is
validated at compile time and just type checked at run time, there is no
code in an interface. The overhead is in the implied super.xxxx() call chain
of the abstract class hierarchy.
Conclusion:
1. No runtime overhead.
2. More flexibility
3. Tighter contract enforcement
4. Accepted design pattern
All good things and in line with your (and mine) draconian contract
adherence.
> The point of the Embedlet specification is to set some basic (and
> inviolate)
> contracts that ALL components (Embedlets, Services and Adapters
> so far) MUST
> abide by. You either fullfil the requirements of being an Embedlet
> component, or not...there is no "middle ground" where you can implement
> "half" of the Embedlet or Component contract. Allowing for full/lite
> versions of such a contract (basically allowing for subsetting of a
> "contract") is a VERY BAD MOVE since then you blur the definition
> of what an
> "acceptable" Embedlet component is. Doing so then requires a lot of
> conditional logic in both the Embedlet and the Container
> implementation to
> check for what "parts" of a contract are being adhered to...which
> leads to
> ugly, inefficient, replicated and hard to maintain code on both sides.
>
> Per your hierarchy comments, adding a ContainerEnabled interface
> opens a bit
> of a pandoras box in this regard, from a philosophical standpoint, and is
> another reason why I left it out, besides the other reasons listed above.
>
> Philosophically, we need to set the line somewhere in the core
> spec. If you
> look at what Component enforces, it's pretty minimal (same with the next
> level down in the inheritance hierarchy for Embedlets, Services and
> Adapters). That was deliberate so that the contract would not be too
> restrictive, but we do need SOME restrictions/requirements. It's
> the nature
> of container-based systems. Core contracts need to be "all or nothing"
> constructs in a container based system.
>
> Where the flexibility lies in "how" these contracts are
> implemented by the
> container, "under the covers", and that flexibility is still there in the
> current code base. Also, what you do in the Lifecycle start()
> method in a
> component is up to the component to define and is not limited by the spec.
>
> For example, how you manage physical storage of Properties is not
> defined in
> the Embedlet core classes.....it's left up to the Container
> implementation
> (and the Outpost RI code provides just such an implementation). All the
> Embedlet spec part does is enforce how you access/manipulate the
> Properties,
> so that all Embedlets written can do this in exactly the same
> manner and be
> assured that (regardless of underlying implementation) they will
> run on any
> container implementation that satisfies these contracts. In fact, we can
> replace the existing Outpost properties implementation with a
> more optimized
> version (probably a good thing to do down the road, based on my prelim
> benchmakrs) without changing a line of Embedlet code. Same with
> Component....it says that the Component has to implement Lifecycle and
> EventConsumer semantics, but does not limit the component or
> container in how
> they choose to do that implementation.
>
> As soon as you start allowing subsetting (eg. lite versions) of
> contracts
> you break the commonality and cause a huge mess for both application and
> container developers.
>
> So I'm rather adamant that the core spec (org.embedlet package)
> interfaces/abstract classes cannot be subsettable. You either
> implement them
> or you don't. If you don't implement org.embedlet.Component then
> you are NOT
> a component that can be managed by a standard-compliant Embedle
> container.
>
> That being said, we do need to discuss and settle on what those core
> contracts should be (I've tried to take a conservative approach
> in the code
> base, and not put in anything more than necessary, so my gut feel
> is that we
> are more likely to add a few things rather than subtract), and
> hence my RFC
> (request for comments). Note that the spec does allow for a lot of
> flexibility since many services are optional. You don't have to
> implement
> Persistence, Management, Mesh or other optional services.
> However, if you DO
> implement one, then it will have to abide by whatever contract we put in
> place for that "type" of service. To be a "bona fide" Embedlet
> Container,
> you DO have to implement Lifecycle, Event, Logging and Timer services.
>
> There is a lot of opportunity for "subsets" or "lite" versions of actual
> container implementations. You can create an implementation that
> fulfills
> the mandatory part of the Embedlet specification, but that only
> implements
> Lifecycle, Event, Logging (using only the Null logger) and Timer, without
> using threads (for example). That would be a pretty "lite"
> container, but
> what is key is that any Embedlet written to the standard (and
> that did not
> require optional services) would run, unchanged, on this "lite" container.
>
> This is another reason why we don't need the ContainerEnabled
> interface right
> now (and probably will never need one).
>
> In summary:
>
> 1) No subsetting/lite versions of key Embedlets contracts (ie. stuff in
> org.embedlet package) allowed, except where whole components or
> features are
> specifically listed as not mandatory (eg. optional services).
>
> 2) Lite/subsetting of container implementation is a good thing
> and expected
> even, so long as it meets the mandatory contracts laid out by the spec.
>
> Sorry 'bout the long diatribe....but I wanted to get my design
> thinking on
> this point out in the open, since it's a very key point, IMNSHO,
> and needs to
> be understood/agreed to by the whole group.
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView,
> The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on
> major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
|
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 23:35:33
|
...myself! And it takes a lot to impress the Emperor of Embedlets. <grins> Just for a lark (since Brill is being lax on getting some real devices JAPL'ed <grins> and cause I don't have any devices to interface to my TINI/JStamp/SaJe boards) I figured I would take a bit of time today and see if the Chaeron open source GPS library will run in the current Outpost container implementation. So I created two embedlets. 1) A GPSMonitorEmbedlet that uses the Chaeron GPS library to talk to one of my GPS units over a serial connection, and receives GPS events, which it then sends attached to an EmbedletEvent of type "event.gps". Since the GPS Library needs to be polled regularly (not all platforms it runs on support threads or javax.comm events) I set up the Embedlet so that it would receive a timer event every 100ms from the TimerService, and used that receipt to trigger the gps.poll() method. The serial port number to use, and what GPS events to listen for (the Chaeron GPS library is also event-oriented) are retrieved from named properties in the Embedlet's Context. 2) The second embedlet was a GPSConsumerEmbedlet, which listens for the "event.gps" EmbedletEvents and just logs the current location/velocity/heading that the GPS is tracking to the default Logging Service. This was tied together with a short mainline routine (GPSEmbedletDemo) which starts up the Outpost Container and hands it the Context info for both embedlets so that they can be automagically started up. The mainline determines what serial port the monitoring embedlet should use and which gps events to listen for. Lo and behold, the damned thing ran exactly as it should on my PC. The monitor received GPS events across the serial port (parsed and "eventized" by the Chaeron GPS library....a JAPL-type of device driver in many ways) and then sent them on to the consumer as EmbedletEvents (using async propagation) which were then displayed using the SimpleLoggingService. I then built this GPS demo application for the TINI. Had to tweak a few platform specific classes in the GPS Library (mainly to do with serial port access and VM information, which is abstracted away in the library so that it can use a pluggable approach to platform-specific stuff), and loaded the executable on the TINI. Hooked up my GPS unit to the TINI's serial port, and damned if it didn't run (well...actually, it kinda crawled, since the TINI is a pretty slow processor to be doing lots of GPS protocol parsing and floating points stuff)...but run it did! So....how's that for a "real" proof of concept? A real external device (serial port connected GPS) polled by a monitoring embedlet using a TimerService periodic timer and sending embedlet events to a consumer embedlet. All on a TINI! yeah....yeah...I know....I should write a web-service oriented Adapter component that takes the GPS data and sends it out over the web. But that's been done already (with my MGDP project) and I don't have the time right now for that. Maybe next weekend I'll do up a Web Services Adapter so we can communicate to the outside world over HTTP. ;-) Nice to know that my GPS Library code will also run on a TINI now too! I'm impressed! Are you impressed? <grins> Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 21:29:50
|
Welcome to the Embedlet Emperor's discussion list. If it wasn't for Ted butting in to respond, all 8 posts would have been from me, in the last Digest version of this list. ;-) Ted said: > Well, as it turns out I have been learning Java3D over the past year or so and > I have already been writing down some blue-sky ideas of ways to leverage it in > a future version of the wiring tool. The way that I got interested in Java3D > was that a number of my students imagined that they wanted to be 3D game > programmers when they grew up and so they started digging into DirectX. After > 6 months of pounding on DirectX they had very little to show for their > efforts. Not a surprise there....I've done more with the 2D Java API than the 3D, but they are productive API's to work with, and eventually the CPU speed makes Java overhead irrelevant. > It might have ended there but these same students had also taken great > pleasure in constantly telling me what a worthless pile of junk Java was and > how it would never replace C for 'real' applications. As soon as they > officially gave up I started digging into Java3D and within about a week or so > I had put together a nice little 3D world on a 1000 meter by 1000 meter plane > which had a number of static and dynamic 3D objects on it. Some of the 3D > objects had .jpg skins on them which contained people's faces (theirs of > course!) and one could easily fly through this world using the keyboard arrow > keys. Just for fun, check out the url: www.codestuds.com If you keep this up, you'll be aiming for membership in this select group, Ted! <grins> > I am not much into games but it is my opinion that Java3D might potentially be > an excellent tool for application visualization and assembly. Possibly.....it would be interesting to see how the boundaries could be pushed with such technology. Might make for a very interesting Graphical Wiring tool. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-08 18:55:44
|
Andrzej stated: > ...you're the Graphics Tool guy. Think you can set something like this up > for us to visualize the evolution of the Embedlet/Outpost code bases over the > > next few years? > > http://perso.wanadoo.fr/pascal.brisset/kernel3d/kernel3d.html > > I want a code management/visualization tool like this. ;-) Well, as it turns out I have been learning Java3D over the past year or so and I have already been writing down some blue-sky ideas of ways to leverage it in a future version of the wiring tool. The way that I got interested in Java3D was that a number of my students imagined that they wanted to be 3D game programmers when they grew up and so they started digging into DirectX. After 6 months of pounding on DirectX they had very little to show for their efforts. It might have ended there but these same students had also taken great pleasure in constantly telling me what a worthless pile of junk Java was and how it would never replace C for 'real' applications. As soon as they officially gave up I started digging into Java3D and within about a week or so I had put together a nice little 3D world on a 1000 meter by 1000 meter plane which had a number of static and dynamic 3D objects on it. Some of the 3D objects had .jpg skins on them which contained people's faces (theirs of course!) and one could easily fly through this world using the keyboard arrow keys. I am not much into games but it is my opinion that Java3D might potentially be an excellent tool for application visualization and assembly. Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 16:46:14
|
Version 1.7 just went up on CVS. Can you mirror to the web site, Ted? Minor changes only: - Added acknowledgement of architecture contributors - Added Ted's cool logo (from the web site). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 16:08:03
|
Just saw this fly by: > Code first, then specify. Anticipatory specs for problems people haven't tried > to solve yet are just wild, random shots in the dark; at best, they waste > everyone's time, and at worst, they cause confusion and hostility. Most > existing XML-related specs should not have been written yet: we don't need a > spec to cover X until many, many people have been trying to implement X for a > while and have discovered where a common spec might be beneficial. A new field > of development shouldn't *start* with a spec; it should *end* with one. > --David Megginson on the xml-dev mailing list, Sun, 27 Oct 2002 Which explains why I have been writing the core Embedlets interfaces/contracts (org.embedlet package) in parallel with the Outpost RI (org.outpost package) and bouncing back and forth, rather than trying to write a specifications document first (in Word, or pdf or some such). The formal spec document will be a natural fallout from the process down the road a bit. Same with a Usage Guidelines document. It also explains why I have been trying to stick rigorously to the KISS principle on the intervaces/contracts side of things, and trying to put as little as possible in the "mandatory" column (versus optional). Good/timely quote. Definitely a keeper for my quotes collection. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 16:06:36
|
...you're the Graphics Tool guy. Think you can set something like this up for us to visualize the evolution of the Embedlet/Outpost code bases over the next few years? http://perso.wanadoo.fr/pascal.brisset/kernel3d/kernel3d.html I want a code management/visualization tool like this. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 15:40:39
|
Chris inquires > On the class hierachy: > > Is there a reason you have not used interfaces as the starting point for the > abstract classes? This requires an extra class(interface) but it provides a > huge amount of flexibility if we need to substitute versions (full/lite) or > platform specific implementations later. > > As you know it would be a simple level to add at the top: > > iComponent > ^ > :__ Component > ^ > |____ Embedlet This was very deliberate on my part. It would be simple to add, and could be done later if needed, without any impact on derived classes, but doesn't add much flexibilty or value at the moment (and has a cost). Let me explain my thinking on that.... The Component method implementations only depend on other core specifications/interfaces (and no other implementation-dependent pieces). That is to say, Component uses stuff from LifecycleEnabled, EventConsumer and Properties, all of which are a mandatory part of the Embedlet standard, and has nothing in it that is or should ever be platform specific. The only class that would ever need to implement the ComponentEnabled interface (regarding naming conventions, I have used XXXXEnabled for interfaces.....LifecycleEnabled, PropertiesEnabled, etc, so would call it ComponentEnabled) is the Component abstract class. There should be no reason to have to implement that interface anywhere else, since managed components must extend (right now) Embedlet, Service or Adapter (which in turn extend Component). Component, as an abstract class, provides the interface definition intrinsically (abstract methods) along with default/mandatory/convenience method implementations that all components will typically need or have to have (eg. setContext() ). Servlets are designed this way....there is no "iServlet" interface....just abstract base classes (GenericServlet and HTTPServlet). There is a fine line with Java best practices on when you use an interface and when to use abstract base classes. I'm basically following those practices here, since the Interface would add nothing in this particular scenario. Adding the interface can also cause method invocations to go through one extra redirection during invocation in many JVMs which will impact performance on contstrained platforms like the TINI. > if we need to substitute versions (full/lite) NO....NO....NO....EMPHATICALLY NO! <grins> The point of the Embedlet specification is to set some basic (and inviolate) contracts that ALL components (Embedlets, Services and Adapters so far) MUST abide by. You either fullfil the requirements of being an Embedlet component, or not...there is no "middle ground" where you can implement "half" of the Embedlet or Component contract. Allowing for full/lite versions of such a contract (basically allowing for subsetting of a "contract") is a VERY BAD MOVE since then you blur the definition of what an "acceptable" Embedlet component is. Doing so then requires a lot of conditional logic in both the Embedlet and the Container implementation to check for what "parts" of a contract are being adhered to...which leads to ugly, inefficient, replicated and hard to maintain code on both sides. Per your hierarchy comments, adding a ContainerEnabled interface opens a bit of a pandoras box in this regard, from a philosophical standpoint, and is another reason why I left it out, besides the other reasons listed above. Philosophically, we need to set the line somewhere in the core spec. If you look at what Component enforces, it's pretty minimal (same with the next level down in the inheritance hierarchy for Embedlets, Services and Adapters). That was deliberate so that the contract would not be too restrictive, but we do need SOME restrictions/requirements. It's the nature of container-based systems. Core contracts need to be "all or nothing" constructs in a container based system. Where the flexibility lies in "how" these contracts are implemented by the container, "under the covers", and that flexibility is still there in the current code base. Also, what you do in the Lifecycle start() method in a component is up to the component to define and is not limited by the spec. For example, how you manage physical storage of Properties is not defined in the Embedlet core classes.....it's left up to the Container implementation (and the Outpost RI code provides just such an implementation). All the Embedlet spec part does is enforce how you access/manipulate the Properties, so that all Embedlets written can do this in exactly the same manner and be assured that (regardless of underlying implementation) they will run on any container implementation that satisfies these contracts. In fact, we can replace the existing Outpost properties implementation with a more optimized version (probably a good thing to do down the road, based on my prelim benchmakrs) without changing a line of Embedlet code. Same with Component....it says that the Component has to implement Lifecycle and EventConsumer semantics, but does not limit the component or container in how they choose to do that implementation. As soon as you start allowing subsetting (eg. lite versions) of contracts you break the commonality and cause a huge mess for both application and container developers. So I'm rather adamant that the core spec (org.embedlet package) interfaces/abstract classes cannot be subsettable. You either implement them or you don't. If you don't implement org.embedlet.Component then you are NOT a component that can be managed by a standard-compliant Embedle container. That being said, we do need to discuss and settle on what those core contracts should be (I've tried to take a conservative approach in the code base, and not put in anything more than necessary, so my gut feel is that we are more likely to add a few things rather than subtract), and hence my RFC (request for comments). Note that the spec does allow for a lot of flexibility since many services are optional. You don't have to implement Persistence, Management, Mesh or other optional services. However, if you DO implement one, then it will have to abide by whatever contract we put in place for that "type" of service. To be a "bona fide" Embedlet Container, you DO have to implement Lifecycle, Event, Logging and Timer services. There is a lot of opportunity for "subsets" or "lite" versions of actual container implementations. You can create an implementation that fulfills the mandatory part of the Embedlet specification, but that only implements Lifecycle, Event, Logging (using only the Null logger) and Timer, without using threads (for example). That would be a pretty "lite" container, but what is key is that any Embedlet written to the standard (and that did not require optional services) would run, unchanged, on this "lite" container. This is another reason why we don't need the ContainerEnabled interface right now (and probably will never need one). In summary: 1) No subsetting/lite versions of key Embedlets contracts (ie. stuff in org.embedlet package) allowed, except where whole components or features are specifically listed as not mandatory (eg. optional services). 2) Lite/subsetting of container implementation is a good thing and expected even, so long as it meets the mandatory contracts laid out by the spec. Sorry 'bout the long diatribe....but I wanted to get my design thinking on this point out in the open, since it's a very key point, IMNSHO, and needs to be understood/agreed to by the whole group. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 14:46:43
|
Nicola: > Hmmm, responsibility is of everybody to the same degree. If we keep > things too separated, knowledge gets shared less... and the project > starts depending too much on a single person. Yes, there are concern > areas, and parts of code that some prefer, but as you have seen > yourself, a natural layering has already occurred ;-) I've already come to this conclusion as well, since my earlier posts. > (discussions get forgotten, just code remains) Not when someone (like moi) takes the key discussions and puts them in a formal document deliverable (like the Architecture document) and soon to be, some Usage Guidelines documents (re: when to use Sync vs Async events, impications of using Properties vs. Instance variables). There is massive value in some of these discussions, and they need preserving and dissemination, and not just in an email archive! <grins> Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 14:36:08
|
> What is the problem with bypassing the container involvment and relying on the > RTOS thread priortization to manage the thread switch? That is what it is > there for! Not every platform we are targeting provides this capability, so we might have to provide different implementations on different platforms. The TINI doesn't have thread priorities, I believe. However, this might be a nice solution for those platforms that do provide RTOS thread prioritization. What I would do is have the send() method raise it's thread priority higher than the async event queue handling threads, send the sync event, then return it's priority to it's starting value. That would effectively block the async threads from executing during the sync event propagation. > 1. The sendEvent(Event) method being thread-safe for synchronous events I believe it is already. > 2. Events would store their own consumer collection (or an event per > consumer) I've thought about this already. This is a non-trivial thing to implement compared to how it is currently done (separate event queue and registered consumer collection, with matching done when the event is "ready" to be propagated, immediately with sync, handled later by the async event dispatcher thread). The problem you run into with having events track their own collection of consumers is that a consumer can be registered or deregistered at any time, which implies that you have to scan the whole list of queued events every time a consumer registration changes, and update each events individual consumer collection. With wildcard matching on event types on the part of consumers, this involves a LOT of duplicate checking (since a consumer could easily appear in more than one event's collection), lots of overhead, and some pretty complex threaded code (with lots of thread synchronization issues), without a lot of benefit to show for it. So I've left it simple at the moment, keeping separate track of event queues and registered consumers. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 14:36:02
|
Chris: Another thought just came to me on properties versus instance variables: Outpost is using stock Hashtables to implement properties at the moment. It could be that some optimization of how properties are implemented under the covers (eg. a custom implementation of a Hashtable rather than using the java.util.Hashtable class) might dramatically improve the performance of property get/sets and make the issue of properties vs instance variable performance more of a moot point in more cases. Let's focus on functionality and interfaces for a bit.....performance optimization is something that we should defer for a bit to see where it will really be needed, especially when it's an implementation detail (in Outpost) which can be transparently changed and not something in the core (Embedlets spec). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 14:21:51
|
Chris comments: > hate... no I actually love, to harp on this. This is the issue that we > went round and round on not so long ago. As I pointed out: > > 1. Performance will suffer due to the variable lookup being in-line with > mission critical code. > 2. Programmers will be reluctant to make every variable access an indirect > call to a context object. >3. The context Hastable becomes a thread contention > item that has to be synchronized, bottle-necking multithreaded access (I did > not point this out but it is a fact). #1 can be a factor, as I found out. However, this is only an impact on functions/embedlets that are exercised frequently (as is the event management code and the benchmark which tries to artificially pump as many events as is possible), which is why it had such a deleterious effect on the benchmark in particular. Many Embedlets will not require this level of performance and will be called less frequently, so it won't be an issue. I'm very reluctant to sacrifice simplicity/consistency on the alter of performance too early in the development/adoption curve, since performance is very much a relative thing and something that is in the eye of the beholder (ie. dependent on the application performance requirements). #2 is definitely NOT true. Servlets are the classic example. Any persistent data is stored in the HTTPSession object, NOT in instance variables. I think there is precedent for this sytle of component development. #3 May be an issue at times. I did some benchmarking and acquiring synchronization locks was not a big factor in the processing speed, even on a TINI. > Reversing the roles so that the Context is only there to provide > initialization properties and to transform/transport Embedlet properties > only when needed, is the way to go, IMNSHO. True enough, to some degree, though it comes at a price, that being that Embedlets have to be written to be thread safe, which is something that many developers have trouble with. Right now, the code base supports both paradigms. What I think is needed (like the sync vs. async events issue) is a Usage Guidelines document that discusses the tradeoffs of one style of usage versus the other, and let the application developer choose which style is most suitable for their purposes (at least until we get real world feedback as to which is the most common usage pattern). Best of both worlds to start....specialize later if need be. In any case, when the next version goes up later this weekend, check out how I handled the "caching" of properties in instance variables (in the org.embedlet.Component base class). Most were read only, initialization values, so that was trivial (they never change after startup). The Lifecycle state value does get updated throughout the life of a component, and it was rather trivial to add this kind of "caching" on an "as required" basis. > I am very impressed with the xRAD development process that you are > demonstrating. Within a couple of days, a critical issue was surfaced, > diagnosed, addressed and fixed! > > My hat off to you! Thanks! Comes with a lot of experience doing the same on commercial projects. In fact, my new consulting gig is to do just that again....create/lead an agile project team to success. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X