embedlets-developer Mailing List for Outpost Embedlet Container (Page 22)
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: Gregg G. W. <gr...@sk...> - 2003-02-24 22:09:24
|
>I've been thinking about how to structure the spec/RI so that we can >support at least some subset of real-time processing, which is a >requirement of many embedded systems. Hard real-time is hard, and is generally something designed specifically for a processor and associated hardware will all latency and hardware speeds are known and planned for. I don't think embedlets help in this realm... >By synchronous event, I mean one that the event manager will process >immediately, without queuing, where the posting of an synchronous event >by and event producer looks more like a procedural method invocation >(albeit an indirect one delegated through the Event Service). This might >be a good way to address certain classes of RT problems, since it will >run in the current thread, and run to completion on a non-preemptive >threading platform. This is what my pub/sub space does for locally connected entities. For connected spaces, it creates a thread to dispatch into that space. In this case there are typically remote access latencies that you don't want local processing to experience. There might be local latencies, or SMP (to take advantage of) that might also make it beneficial to have two threads running to maximize throughput. >The problem here is if this capability is abused. If a single sync event >produces multiple child sync events (event cascade scenario) or a >circular situation, then you can go into an infinite loop or blow the >stack space. If running on a pre-emptive platform, then you can easily >run into situations that are not thread-safe. Yes, all of these things are true, including the posibility of exceptions that may need to be passed up to defer procesing... >That being said, I think it's worthy of inclusion, with appropriate >caveats/warnings/best practices to keep developers from getting into >troubles. >Any other thoughts/collective wisdom on Real Time support for Embedlets? Soft typically implies predictable latencies with reasonable limits for windows into the latency times. I am not sure that you can ever, really cap the windows maximum, without more explicit controls such as those that RTSJ provides... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-24 21:55:05
|
Gregg suggests: > We wanted to do all of these, and Jini LUS users want all of these. But > in the end, it is simpler to limit the criteria. For pub/sub, I'd still > suggest a simple hierachial topic string system, and that you should just > include the appropriate parts in the topics. Predefined topic trees would > be beneficial, but using properties to configure modules to use the > appropriate topic simplifies the whole mess by delaying this issue till > deployment which can allow some modules to be used in ways that were not > originally in the design. > > control.switch.off.1.<producer> > > is an example topic, where everything is specified. In a topic system, at > deployment time, you could match with > > control.switch.*.1.* I like it. It's a nice way to keep things simple, provides some optimization opportunities along the way, and gives the developers a very extensible event typing/matching system that should be more than enough for their needs in the embedded space. Unless anyone has any objections (or better suggestions), I'll structure the Event Manager Service specifications along these lines. The only thing I think I would do differently is to keep the <producers> and/or <consumer> critera out of the topic string, since this would allow for much more efficient filtering on the part of the Event Manager without adding much in the way of complexity for the developer. Conceptually, it also keeps things a touch clearer since who produced (or should be allowed to consume an event) is not really part of the event type (or topic). > I do have a broadcast 'space' that includes single copy delivery in a mesh > environment, and topic based pub/sub, that I am willing to 'donate' to the > cause... Is this a JINI space? ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-24 20:58:32
|
I've been thinking about how to structure the spec/RI so that we can support at least some subset of real-time processing, which is a requirement of many embedded systems. There are many fuzzy definitions of real-time. Hard real-time seems to be the most stringent, and looks like a pre-emptive interrupt driven scheme that keeps things like planes from crashing and chemical plants from blowing up. I'm pretty sure that these most stringent of requirements for response to critical interrupts will not be a good fit for the Embedlet architecture, at least not in the first few iterations, since they very much rely on the underlying hardware capabilities (to provide the deterministic, interrupt-processing stuff), and there are not too many RTJ (real time for Java) implementations out there. Many Java implementations of threads are not pre-emptive which is something the Embedlet container can't easily address. However, this does leave a large middle ground, for the implementation of "softer" real-time requirements. A typical event-driven paradigm (like the one we have been discussing and planning on implementing), with a decoupling queue in the middle (the Event Service) does not provide deterministic response times and so compromises hard real-time capability, though a simple/flexible event priority scheme might go a long way to mitigate this, and would allow for many "soft" rt application implementations. The concept of synchronous events might work to handle this, with suitable caveats/provisos in how they should be used (so as not to compromise overall performance, and blow the stack space). By synchronous event, I mean one that the event manager will process immediately, without queuing, where the posting of an synchronous event by and event producer looks more like a procedural method invocation (albeit an indirect one delegated through the Event Service). This might be a good way to address certain classes of RT problems, since it will run in the current thread, and run to completion on a non-preemptive threading platform. The problem here is if this capability is abused. If a single sync event produces multiple child sync events (event cascade scenario) or a circular situation, then you can go into an infinite loop or blow the stack space. If running on a pre-emptive platform, then you can easily run into situations that are not thread-safe. That being said, I think it's worthy of inclusion, with appropriate caveats/warnings/best practices to keep developers from getting into troubles. Any other thoughts/collective wisdom on Real Time support for Embedlets? ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-02-24 18:11:22
|
Very slick ;) - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Monday, February 24, 2003 4:23 AM Subject: [Embedlets-dev] [management] Embedlets.org lives! (and Forrest rocks!) > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Embedlets.org lives and Forrest absolutely rocks! (thanks Nicola!). > > Its not perfect, and it could probably use some editing, but at least we have a > site up now. > > http://embedlets.org > > I directed both embedlets.org and embedlet.org to the site and if people think > that japl.org should be directed there too for the time being just let me know. > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-02-24 09:23:21
|
Embedlets.org lives and Forrest absolutely rocks! (thanks Nicola!). Its not perfect, and it could probably use some editing, but at least we have a site up now. http://embedlets.org I directed both embedlets.org and embedlet.org to the site and if people think that japl.org should be directed there too for the time being just let me know. Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-24 02:24:42
|
>The Embedlet Event Manager service will provide the ability for an event >consumer to specify criteria for the events they want to receive, and >this will include more than just the "type" of the event (since that is >pretty coarse grained). > >You'll be able to subscribe to events by: > > - event type > - producer (specific sender) > - various other properties (either user or system properties in the > event). > - Any combination of the above. The more complex you make the decision logic, the more overhead will be involved in 1) executing the logic 2) defining the interaction of the criteria (and, or, xor and not) 3) educating users to use it correctly so that the documentation and the implementations match. We wanted to do all of these, and Jini LUS users want all of these. But in the end, it is simpler to limit the criteria. For pub/sub, I'd still suggest a simple hierachial topic string system, and that you should just include the appropriate parts in the topics. Predefined topic trees would be beneficial, but using properties to configure modules to use the appropriate topic simplifies the whole mess by delaying this issue till deployment which can allow some modules to be used in ways that were not originally in the design. control.switch.off.1.<producer> is an example topic, where everything is specified. In a topic system, at deployment time, you could match with control.switch.*.1.* to get all of switch 1 actions from all producers. A single type of subscription, such as this, allows optimizations to be designed into the system, but letting presupplied topics to be 'compiled' to match optimally. When you include a more complex arrangement, such as an object that includes values for all of these, such as new Event( SWITCH_CONTROL.ANY, 1, "*" ) you get a more complex system that is not very expandable, when the user actually has several other critera that they need to match on. I do have a broadcast 'space' that includes single copy delivery in a mesh environment, and topic based pub/sub, that I am willing to 'donate' to the cause... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-24 00:25:40
|
Ted asks: > What is your perspective on JavaOS's Bidirectional Events (section 3.5)? The only thing you need to support bidirectional events is a way to identify the event that you are responding to. That would be easily done if the producer tags the event with a unique id prior to sending it. Then when a consumer received it, and wanted to send a response, it would tag the response with the original unique id. I'ld rather not explicitly build this into the core Event Manager service just yet (trying to keep things simple for the moment), since the basic pub/sub event capability will allow for it for those apps that need it. Then we can see how much a request/response (bi-di) paradigm is required and whether it makes sense to make it a standard feature. In the meantime, it's not that hard to do req/resp event conversations by using two different event types, a unique id, with two embedlets that register as both producers and consumers. ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-23 00:19:16
|
Ted Kosan wrote, On 23/02/2003 0.41: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Andrzej stated, ... > Yes, the more we discuss the publish/subscribe model the more I am grasping it > and now I am looking forward to playing with it too! In the PLC world, the publish/subscribe model is IMHO a killer feature. We have seen that it makes it much easier to do stuff, and can greatly decrease timing problems. It was even mentioned in this JSR: http://www.jcp.org/en/jsr/detail?id=50 [does anyone know what happened to all these automatiuon JSRs?] Here where I work, it seems that Rockwell Automation seems to gain ground with de-facto standards: http://www.ab.com/catalogs/b113/comm/ethernet.html http://www.ab.com/catalogs/b113/comm/cnet.html http://www.ab.com/catalogs/b113/comm/dnet.html Here are other links to some related stuff I bookmarked. http://ethernet.industrial-networking.com/articles/i12protocols.asp http://www.macrolinx.com/document/rel/industry-Ethernet-Control-Solutions.pdf http://www.manukau.ac.nz/departments/e_e/research/2002/kb.pdf -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Ted K. <tk...@ya...> - 2003-02-22 23:41:52
|
Andrzej stated, > The Embedlet Event Manager service will provide the ability for an event > consumer to specify criteria for the events they want to receive, and > this will include more than just the "type" of the event (since that is > pretty coarse grained). > > You'll be able to subscribe to events by: > > - event type > - producer (specific sender) > - various other properties (either user or system properties in the > event). > - Any combination of the above. > > So a particular event consumer (eg. an embedlet) will be able to receive > only the events it really wants to get and no others. > > Might also add the ability for a producer to specify a specific > consumer(s) that are allowed to receive a specific event (might be useful > for security). > > Does that answer your concern, Ted? Yes, the more we discuss the publish/subscribe model the more I am grasping it and now I am looking forward to playing with it too! What is your perspective on JavaOS's Bidirectional Events (section 3.5)? Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-22 22:56:29
|
Ted asks:
> If the Embedlet produces SwitchEvents, does this mean that every other
> Embedlet in the application that consumes SwitchEvents will be forced to
> subscribe to this event source?
>
> What if one had 10 JAPL input bits that were being polled by 10 Embedlets
> which all generated SwitchEvents? Would all SwitchEvent consumers in the
> application be forced to subscribe to all of these event sources?
The Embedlet Event Manager service will provide the ability for an event
consumer to specify criteria for the events they want to receive, and
this will include more than just the "type" of the event (since that is
pretty coarse grained).
You'll be able to subscribe to events by:
- event type
- producer (specific sender)
- various other properties (either user or system properties in the
event).
- Any combination of the above.
So a particular event consumer (eg. an embedlet) will be able to receive
only the events it really wants to get and no others.
Might also add the ability for a producer to specify a specific
consumer(s) that are allowed to receive a specific event (might be useful
for security).
Does that answer your concern, Ted?
...Andrzej
Chaeron Corporation
http://www.chaeron.com
|
|
From: Brill P. <bri...@ro...> - 2003-02-22 16:58:57
|
> I have not yet been able to get my mind around the concept of a 100% > publish/subscribe system. For example, lets say that one has a toggle switch > hooked up to a JAPL input bit and then there is an Embedlet which holds a > reference to this JAPL peripheral and it polls it once per second. > > If the Embedlet produces SwitchEvents, does this mean that every other Embedlet > in the application that consumes SwitchEvents will be forced to subscribe to > this event source? Whether I agree with you or not, the way you handle that is by allowing the subscribers to define which events they should get, be they from a particular switch, or a particular event type (pressed, released). etc... - Brill |
|
From: Ted K. <tk...@ya...> - 2003-02-22 08:31:52
|
Andrzej stated:
>One of the beauties of pub/sub is the publisher usually doesn't
>care who is getting the events (decoupled messages), which defines
>"filtering" from the perspective of the consumer only (all the
>producer does is "tag" the message with properties that consumers
>might want to use for filtering purposes). This provides for a
>very dynamic, self-configurable, and easily extensible environment
>(eg. to add logging of a particular event type, you just drop in a
>logging Embedlet that registers interest in receiving that particular
>event, and the producer neither cares nor knows that a new consumer
>was added). But there are situations (maybe for security reasons)
>that the producer might want to specify what consumers are eligible
>to receive a particular event. Or maybe we'll need filtering at
>both consumer and producer ends.
I have not yet been able to get my mind around the concept of a 100%
publish/subscribe system. For example, lets say that one has a toggle switch
hooked up to a JAPL input bit and then there is an Embedlet which holds a
reference to this JAPL peripheral and it polls it once per second.
If the Embedlet produces SwitchEvents, does this mean that every other Embedlet
in the application that consumes SwitchEvents will be forced to subscribe to
this event source?
What if one had 10 JAPL input bits that were being polled by 10 Embedlets which
all generated SwitchEvents? Would all SwitchEvent consumers in the application
be forced to subscribe to all of these event sources?
JavaOS uses a publish/subscribe event model, but it also includes peer-to-peer
event capabilities in order to solve this problem. Here is an excerpt from
'Inside the JavaOS Operating System' that talks about this:
Suppose that an event consumer wants to receive events from one or more
specific producers. In other words, the consumer does not want to register to
receive events by type, it wants to receive events from particular producers.
To find a registered producer from which to receive events, the consumer class
retrieves an OSEventProducerEnumerator object from the event manager by calling
the producers() method. Next, the consumer calls the nextElement() method of
this class to retrieve a reference to each producer object in the list. When
the consumer locates the producer it wants to work with, it calls the static
connectConsumer() method in OSEventProducer with a reference to the producer
object. The consumer then will receive events from that producer alone. The
consumer can specify whether it wants to be the exclusive consumer of events
from that producer. Again, this is useful for security reasons.
In a similar fashion, a registered consumer can be located by first
retrieving [snip]
Oh heck, here is the complete events chapter:
http://tkosan.javadevices.org/misc/embeddedjava/JavaOS_Events.html
There is so much good material here related to what we are doing that I suppose
one can not do it justice by just copying 'sound bites' from it.
I especially like the following sections:
3.3.2 Producer Classes
3.4.3 Peer-to-Peer Registration
3.5 Bidirectional Events
Ted
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
|
|
From: Holger B. <ho...@bi...> - 2003-02-20 22:12:38
|
Am Donnerstag, 20.02.03, um 21:41 Uhr (Europe/Budapest) schrieb Andrzej Jan Taramina: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > bax gushes: > >> kisses for this ! > > Just cause we're doing embedlets together, doesn't mean we should start > getting in bed, lets! <grins> ... just an option ;-) Have had nothing appropriate at hand. I am not a native english writer nor speaker. Just expressing my feelings about the just performed reading ... Substitute with 'Great!' for the one i might have had scared. bax |
|
From: Christopher S. <cs...@oo...> - 2003-02-20 21:43:45
|
I am about to redirect my email DNS to another provider so I may drop off the face of the earth for a day or so. An alternate email if you need to contact me directly is thi...@ao... |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-20 20:42:18
|
bax gushes: > kisses for this ! Just cause we're doing embedlets together, doesn't mean we should start getting in bed, lets! <grins> Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Holger B. <ho...@bi...> - 2003-02-20 20:22:09
|
kisses for this ! bax ;-) Am Donnerstag, 20.02.03, um 20:04 Uhr (Europe/Budapest) schrieb Brill Pappin: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Ok, this *is* off topic, but I thought it was interesting enough > seeing as > we're defining specifications. I have no idea who wrote it... it came > in the > mail with all the stuff friends send you: > >> And you wonder why...! The US standard railroad gauge (width between >> the > two rails) is 4 feet 8.5 inches. That's an exceedingly odd number. Why > was > that gauge used? Because that's the way they built them in England, > and the > US railroads were built by English expatriates. Why did the English > build > them like that? Because the first rail lines were built by the same > people > who built the pre-railroad tramways, and that's the gauge they used. > Why did > "they" use that gauge then? Because the people who built the tramways > used > the same jigs and tools that they used for building wagons which used > that > wheel spacing. Okay! Why did the wagons have that particular odd wheel > spacing? Well, if they tried to use any other spacing, the wagon wheels > would break on some of the old, long distance roads in England, because > that's the spacing of the wheel ruts. So who built those old rutted > roads? > The first long distance roads in Europe (and England) were built by > Imperial > Rome for their legions. The roads have been used ever since. And the > ruts in > the roads? Roman war chariots first formed the initial ruts, which > everyone > else had to match for fear of destroying their wagon wheels. Since the > chariots were made for (or by) Imperial Rome, they were all alike in > the > matter of wheel spacing. The United States standard railroad gauge of 4 > feet, 8.5 inches derives from the original specification for an > Imperial > Roman war chariot. Specifications and bureaucracies live forever. So > the > next time you are handed a specification and wonder what horse's ass > came up > with it, you may be exactly right, because the Imperial Roman war > chariots > were made just wide enough to accommodate the back ends of two war > horses. > Thus, we have the answer to the original question. Now the twist to the > story...! There's an interesting extension to the story about railroad > gauges and horses' behinds. When we see a Space Shuttle sitting on its > launch pad, there are two big booster rockets attached to the sides of > the > main fuel tank. These are solid rocket boosters, or SRBs. The SRBs are > made > by Thiokol at their factory in Utah. The engineers who designed the > SRBs > might have preferred to make them a bit fatter, but the SRBs had to be > shipped by train from the factory to the launch site. The railroad > line from > the factory had to run through a tunnel in the mountains. The SRBs had > to > fit through that tunnel. The tunnel is slightly wider than the railroad > track, and the railroad track is about as wide as two horses' behinds. > So, > the major design feature of what is arguably the world's most advanced > transportation system was determined over two thousand years ago by the > width of a Horse's Ass. And you wonder why we are the way we are...! > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-20 19:45:11
|
Ted notes: > there is nothing quite like reading a > Java technical book by the light of a Kerosene lamp Ah! I'm glad I'm not the only one that appreciates such a scenario! Then again, I live in the country as well....and have been known to read tech manuals by kerosene/propane/candle light at the cottage! Hope you get power soon! Then Brill pipes in with: > The major design feature of what is arguably the world's most advanced > transportation system was determined over two thousand years ago by the > width of a Horse's Ass. So are you suggesting that embedlets or JAPL interfaces be the width of a horses ass? A critical design decision to be sure. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-20 19:41:54
|
Chris clarifies:
> Because you want to have a name or description that has meaning to an
> operator ('Crude Oil Feed - west tower'), may be changed to match local or
> variant situations or may need to support internationalization.
Ah.....I distinguish between a Name/ID (which I see as identical, a unique
identifier for the component/container) versus a Description. Both are good
to have.
Another one of those miscommunications issues is all....we're in violent
agreement.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-20 19:40:37
|
Chris says: > A formal schema will 'fall out' of the XML configuration design quite > naturally and I would expect it to be a part of the specification. Yup...I agree. We'll define the XML Config documents as we go, and once they stabilize, then we'll encode that in a Schema. The only thing you need a schema for is validation....which is not needed till later in the development/release cycle. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-20 19:24:36
|
Very good! This sounds like a John Burke - Scientific American Connections column and PBS series of the same name. > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Ok, this *is* off topic, but I thought it was interesting enough seeing as > we're defining specifications. I have no idea who wrote it... it > came in the > mail with all the stuff friends send you: > > >And you wonder why...! The US standard railroad gauge (width between the > two rails) is 4 feet 8.5 inches. That's an exceedingly odd number. Why was > that gauge used? Because that's the way they built them in > England, and the > US railroads were built by English expatriates. Why did the English build > them like that? Because the first rail lines were built by the same people > who built the pre-railroad tramways, and that's the gauge they > used. Why did > "they" use that gauge then? Because the people who built the tramways used > the same jigs and tools that they used for building wagons which used that > wheel spacing. Okay! Why did the wagons have that particular odd wheel > spacing? Well, if they tried to use any other spacing, the wagon wheels > would break on some of the old, long distance roads in England, because > that's the spacing of the wheel ruts. So who built those old rutted roads? > The first long distance roads in Europe (and England) were built > by Imperial > Rome for their legions. The roads have been used ever since. And > the ruts in > the roads? Roman war chariots first formed the initial ruts, > which everyone > else had to match for fear of destroying their wagon wheels. Since the > chariots were made for (or by) Imperial Rome, they were all alike in the > matter of wheel spacing. The United States standard railroad gauge of 4 > feet, 8.5 inches derives from the original specification for an Imperial > Roman war chariot. Specifications and bureaucracies live forever. So the > next time you are handed a specification and wonder what horse's > ass came up > with it, you may be exactly right, because the Imperial Roman war chariots > were made just wide enough to accommodate the back ends of two war horses. > Thus, we have the answer to the original question. Now the twist to the > story...! There's an interesting extension to the story about railroad > gauges and horses' behinds. When we see a Space Shuttle sitting on its > launch pad, there are two big booster rockets attached to the sides of the > main fuel tank. These are solid rocket boosters, or SRBs. The > SRBs are made > by Thiokol at their factory in Utah. The engineers who designed the SRBs > might have preferred to make them a bit fatter, but the SRBs had to be > shipped by train from the factory to the launch site. The > railroad line from > the factory had to run through a tunnel in the mountains. The SRBs had to > fit through that tunnel. The tunnel is slightly wider than the railroad > track, and the railroad track is about as wide as two horses' behinds. So, > the major design feature of what is arguably the world's most advanced > transportation system was determined over two thousand years ago by the > width of a Horse's Ass. And you wonder why we are the way we are...! > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-20 19:05:53
|
Ok, this *is* off topic, but I thought it was interesting enough seeing as we're defining specifications. I have no idea who wrote it... it came in the mail with all the stuff friends send you: >And you wonder why...! The US standard railroad gauge (width between the two rails) is 4 feet 8.5 inches. That's an exceedingly odd number. Why was that gauge used? Because that's the way they built them in England, and the US railroads were built by English expatriates. Why did the English build them like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the gauge they used. Why did "they" use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons which used that wheel spacing. Okay! Why did the wagons have that particular odd wheel spacing? Well, if they tried to use any other spacing, the wagon wheels would break on some of the old, long distance roads in England, because that's the spacing of the wheel ruts. So who built those old rutted roads? The first long distance roads in Europe (and England) were built by Imperial Rome for their legions. The roads have been used ever since. And the ruts in the roads? Roman war chariots first formed the initial ruts, which everyone else had to match for fear of destroying their wagon wheels. Since the chariots were made for (or by) Imperial Rome, they were all alike in the matter of wheel spacing. The United States standard railroad gauge of 4 feet, 8.5 inches derives from the original specification for an Imperial Roman war chariot. Specifications and bureaucracies live forever. So the next time you are handed a specification and wonder what horse's ass came up with it, you may be exactly right, because the Imperial Roman war chariots were made just wide enough to accommodate the back ends of two war horses. Thus, we have the answer to the original question. Now the twist to the story...! There's an interesting extension to the story about railroad gauges and horses' behinds. When we see a Space Shuttle sitting on its launch pad, there are two big booster rockets attached to the sides of the main fuel tank. These are solid rocket boosters, or SRBs. The SRBs are made by Thiokol at their factory in Utah. The engineers who designed the SRBs might have preferred to make them a bit fatter, but the SRBs had to be shipped by train from the factory to the launch site. The railroad line from the factory had to run through a tunnel in the mountains. The SRBs had to fit through that tunnel. The tunnel is slightly wider than the railroad track, and the railroad track is about as wide as two horses' behinds. So, the major design feature of what is arguably the world's most advanced transportation system was determined over two thousand years ago by the width of a Horse's Ass. And you wonder why we are the way we are...! |
|
From: Ted K. <tk...@ya...> - 2003-02-20 10:07:36
|
As I indicated in an earlier post, we had an ice storm move through Southern Ohio last weekend which brought down thousands of trees and snapped a significant number of power poles. We have been without power since Sunday and the latest estimate is that the area that I am in will not have power until Saturday. We bought a generator today so I will attempt to get to things like putting up the embedlets website and redirecting the embetlet.org and embedlets.org websites within the next few days. You know, things like not having electricity, not being able to get out of the driveway (its 1/8th of a mile long), not being able to take a hot shower and loosing all of the food in the freezer were not so much of a problem but for me not having access to the Internet was a real killer! ;-) One good thing that came out of this is that I did manage to get a 100 pages into Hatcher and Loughran's new 'Java Development with Ant' book. So far it has been excellent and I have found that there is nothing quite like reading a Java technical book by the light of a Kerosene lamp... Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Christopher S. <cs...@oo...> - 2003-02-20 04:52:43
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> >> Differences between Hardware and Software are simply not existent.
> >> Show
> >> me the if they exist.
> >>
> >> Mostly the hardware today _is_ in fact Software. Not only the
> >> micrcodes, but in the process of development and construction. I am
> >> not
> >> able to construct any thing more complicated than a binkenlight
> >> without
> >> Software in it.
> >>
> > Agreed that there is a great deal of overlap. The general concept of a
> > declarative language that generates an operational system is also a
> > common
> > theme. As I stated in an earlier post there are a number of synergies.
> > The
> > key differences that I have picked up on are:
> >
> > 1. The Embedlets specification is about how to package Java objects so
> > that
> > they behave like hardware, with defined inputs and outputs, triggers
> > (events) etc, while retaining an object oriented environment within the
> > component.
>
> This met the behavioral concept in VHDL.
Here is a brief clip of VHDL:
entity latch is
port (s,r: in bit;
q,nq: out bit);
end latch;
I do not know many programmers who would recognize this as an object
oriented contruct, especially one that they would like to learn.
>
> > HDL is about generating fast and compact systems from predefined
> > components
> > (logical building blocks etc).
>
> This maps to the architectural concept of VHDL, the entities.
>
> > 2. The Embedlets specification defines extended services that allow
> > embedded
> > systems to integrate with enterprise systems, each other and hardware
> > in
> > standardized re-usable ways.
> >
> > You could do this in HDL but you would have to come up with the same
> > type of
> > services and standards.
>
> Here met VHDL JHDL. We may take the wave and define services (which i
> expect mostly FSM are in the so called 'embedded world' - not the fair
> ;) and standards in a emerging standard way - in pure Java.
Services are not related to Finite State Machines but rather underlying
infrastructure support: communication, persistence, lookup etc. As I said
there is no doubt that they could be implemented in HDL or its variants -
but then you would be re-inventing the wheel in a domain that is outside
that of the original scope of HDL.
>
> > 3. The embedlet configurations are based on XML which provides a
> > parsable,
> > self documenting, open standards format.
>
> uppps, where is the task for providing the schema (xsd) for this?
A formal schema will 'fall out' of the XML configuration design quite
naturally and I would expect it to be a part of the specification.
> Whithout this, XML degrades to a textfile with '<', '<' and '/'.
That happens to have 100s of readily available tools, overwhelming industry
acceptance, a natural object representation format, WEB enabling technology
(xslt), volumes of documentation and training material...
>
> > HDL is dependent on the 'C' preprocessor and compiler and requires
> > learning
> > (yet) another language.
>
> Wrong, have a look at the opensourced JHDL project.
I have - it is an improvement but will still get a lot of resistence from
OO/Java developers. For example the statement:
or_o( and(a,b), and(a,cin), and(b,cin), cout ); /* cout is output */
indicates that there is a syntax defined by the or_o() and and() super class
Logic methods which is overlaying the native Java syntax. This seems to have
flattened Java OOP to many static function calls in the Logic class. An XML
based represenation would retain the OO recognizable structure and
declarations without requiring a new syntax, just a new XML schema eg:
<SupplyAnd Name="SupplyGate" Identity="AND_GATE_01"
Class="com.oopscope.opc.node.BinaryAnd" Inverting="true">
<Inputs Size="2" Identity="GATE_01_INPUTS"
Class="com.oopscope.opc.persistence.PersistentCollection">
<Input href="INVERTER_01"/>
<Input href="INVERTER_02"/>
</Inputs>
</SupplyAnd>
This also supports dynamic configuration - something that would be very
difficult using a language based tool such as HDL and its variants.
>
> > The Embedlets space is different and compelling enough to justify a
> > distinct
> > specification utilizing enterprise standards and techniques.
>
> This is the exact sentence my marketing manager say to me if he want to
> have it proprietary, not standard compliant, or simply does not know
> what argument should provide enough power otherwise.
>
> Sorry, for being frankly :)
The statement was made to indicate that there is enough interest among the
participants and (we believe) the general development community to warrant
the effort. It will benefit from constructive input from a variety of
related fields, which is always welcome and will lead to my suggestion
below.
>
> > My suggestion is that we look for commonality and areas where
> > interoperablility is possible. JHDL looks like a move in that
> > direction.
>
> yeap, last sentence. But enough todo even, it is Version 0.3.
>
> bax
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
|
|
From: Christopher S. <cs...@oo...> - 2003-02-20 03:52:43
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > FYI: meanwhile the DNS Server service is deprecated (same like NIS and > friends), it make more sense to use an LDAP for this tasks. > Roger that, DNS was being used in a generic sense. > bax > > Am Mittwoch, 19.02.03, um 23:52 Uhr (Europe/Budapest) schrieb > Christopher Smith: > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > >> > >> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > >> _______________________________________________ > >> > >> Brill asked and Chris responded: > >> > >> I don't think this is off topic at all.....components (embedlets, > >> services, > >> adapters and devices) will need internal names, along with a name for > >> the > >> Outpost container itself. > >> > >>> The container should have a unique identity that could be > >> concatenated with > >>> the embedlet/JAPL id. > >>> > >>> Since the devices are likely to be at the end of a DNS, it > >> would probably make > >>> sense to structure the path as a URL: > >>> > >>> http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID > >> > >> If a company has thousands of embedded processors deployed, it's > >> unlikely > >> that they will use DNS names for them, since maintaining that many DNS > >> entries is a big task. More likely they will just allocate IP > >> addresses. > > > > It may actually make a lot of sense to use a DNS to keep a database of > > ips, > > since that is what they do. It would be especially useful in a large > > installation such as an oil refinery: > > > > http://holdingTank114.elsugundo.unionoil.com:8180/tankMonitor/oilLevel > > > > This assumes that there can be more than one container at a given ip > > address, the container address would be omitted if not. > > > > The address resolution would be distributed to each level of the > > hierarchy: > > DNS(domain)/IPDaemon(port)/Controller/Container/Embedlet > > > >> > >> That being said, the idea has merit. What I'm planning to put in > >> the spec is > >> that the user will be able to assign names to all the components and > >> the > >> container (as strings) in the XML Config files, and in the case of the > >> container itself, allow this to be overriden in the deployment > >> process (so > >> that multiple identical containers can had unique names). But I was > >> not > >> planning on specifying what the names should look like....would > >> rather just > >> allow any arbitrary string, and let the client use whatever > >> naming standard > >> makes sense for them (since they may already have corporate standards > >> for > >> this). > >> > > > > There should be a name AND an identity (you may have stated this but I > > just > > wanted to emphasize to point). The name is used for human consumption > > and > > can change, the identity is fixed for the life of the configuration > > and is > > used for internal reference. > > > >> Brill continued: > >> > >>> Sure... though I wasn't trying to come up with an ID for > >> embedlets and it > >>> needs to work without an embedlet system present. however that > >> is certainly a > >>> workable solution. > >> > >> I'ld be wary of imposing naming conventions, since clients may > >> already have > >> their own. Just provide a name string, with getName()/setName() > >> methods. If > >> the JAPL device is running under the control of an Embedlet > >> Container, then > >> the Embedlet would likely read the device id from the XML config file > >> and > >> issue the setName() property on the devices behalf. > >> > >>> Yes, that's pretty much what I'd like to do... what I need to > >> decide is how > >>> the id is generated etc, and who names the container? > >> > >> If we provide a generic, string-based naming ability, the client can > >> do > >> whatever makes sense for them. > >> > >>> So, the id's can be auto generated during negotiation and > >> start-up, or they > >>> can be named parameters in some sort of property set... for > >> embedlets the > >>> named approach makes sense. > >> > >> I would let the client provide the auto-gen id code as part of > >> the deployment > >> process. > >> > >> > >> Andrzej Jan Taramina > >> Chaeron Corporation: Enterprise System Solutions > >> http://www.chaeron.com > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > >> The most comprehensive and flexible code editor you can use. > >> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > >> www.slickedit.com/sourceforge > >> _______________________________________________ > >> Embedlets-developer mailing list > >> Emb...@li... > >> https://lists.sourceforge.net/lists/listinfo/embedlets-developer > >> > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > > The most comprehensive and flexible code editor you can use. > > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Christopher S. <cs...@oo...> - 2003-02-20 03:32:30
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris suggests:
>
> > It may actually make a lot of sense to use a DNS to keep a
> database of ips,
> > since that is what they do. It would be especially useful in a large
> > installation such as an oil refinery:
>
> That's true...but the guys deploying the devices may not have the
> knowledge
> nor access to the corporate DNS servers. And the glass house guys
> probably
> won't want to implement DNS lookups for thousands of devices.
>
> Be great if they did though. ;-)
>
> > There should be a name AND an identity (you may have stated
> this but I just
> > wanted to emphasize to point). The name is used for human
> consumption and can
> > change, the identity is fixed for the life of the configuration
> and is used
> > for internal reference.
>
> Why not just use a string based identiy that can be used for both?
Because you want to have a name or description that has meaning to an
operator ('Crude Oil Feed - west tower'), may be changed to match local or
variant situations or may need to support internationalization.
An identity should not be changed because it is the key to embedlet lookup
and relationships. Identities are usually pretty terse or even numeric for
improved lookup performance making them a poor choice for user interaction.
You may want to auto-number and validate identities for uniqueness as part
of the deployment.
A typical situation is where a system is installed and working fine, but
there is some confusion about what embedlet does what due to poor initial
naming. Renaming with a separate name property is benign, with a common
identity it could be disastrous.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
|
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X