embedlets-developer — Outpost Embedlet container developer list

[Embedlets-dev] Re:[Marketing] Embedlets and the Innovator's Dilemma....

[Ted K. <tk...@ya...>]

Andrzej,

Very interesting article!



> Again, it's very possible (if embedlets become a "disruptive technology" in
> the embedded 
> space), that the initial adopters of this technology are not even known to us
> right now.

This brings to mind an article by Clay Shirky about some of the fundamental
reasons that the Web built out so quickly:

http://www.shirky.com/writings/view_source.html

I especially like his philosophy of focusing on what a technology can 'do', not
what it is 'for':

----

"#3. Good tools tell you what they do, not what they're for.

Good, general-purpose tools specify a series of causes and effects,
nothing more. This is another part of what allowed the Web to grow so
quickly. When a piece of software specifies a series of causes and
effects without specifying semantic values (gravity makes things fall
to the ground, but gravity is not for keeping apples stuck to
the earth's surface, or for anything else for that matter), it
maximises the pace of innovation, because it minimizes the degree to
which an effect has to be planned in advance for it to be useful.

The best example of this was the introduction of tables, first
supported in Netscape 1.1. Tables were originally imagined to be just
that - a tool for presenting tabular data. Their subsequent adoption
by the user community as the basic method for page layout did not have
to be explicit in the design of either HTML or the browser, because
once its use was discovered and embraced, it no longer mattered what
tables were originally for, since they specified causes and effects

that made them perfectly suitable in their new surroundings" [snip]


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

[Embedlets-dev] [wiring] Wiring tool inspiration program

[Ted K. <tk...@ya...>]

There was an ice storm here in Southern Ohio and we have been without power for
two days.  I was able to figure out a way to access the net for a half hour or
so but I will not be online again until the power comes on.

In the mean time, one of the developers that Bruce found on the Lego list
has turn out to be a fabulous resource.  His name is Peter Balch and he is
somewhat of an expert in graphical programming languages.

He sent me a copy of a research program he had developed awhile back and after
looking at it I think that it has some good ideas that can possibly be used in
the Embedlets wiring tool.

Here is a link to the program in case anyone wants to take a look at it:

http://tkosan.javadevices.org/misc/embeddedjava/Filter.zip


Unfortunately Peter says that he could not find all of the DLLs for the program
so it is not completely functional but the graphical editor works fine and this
is what we are mostly interested in anyway.

Peter has been passing along to me a number of pitfalls he ran into when
developing this and other graphical research languages and so hopefully this
information will prove to be helpful to us.

As an example of this, Peter indicated that placing the graphical components on
a grid turned out to be much cleaner than just wiring them free form.  I think
that we will probably include a number of ways to views wired Embedlets
including a grid view and also free-form view but I had not thought about the
grid view until Peter mentioned it.

Anyway, the components that Peter included with Filter are not necessarily good
candidates for Embedlets but the way that they are connected together looks
interesting.  I recommend first opening up some of the pre-wired applications
that are included with Filter before trying to wire together any from scratch.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

RE: [Embedlets-dev] Device polling

[Christopher S. <cs...@oo...>]

In regards to event vs state driven control: I see an issue with strictly
event driven Embedlets. The scenario for an industrial control is:

1. An output (embedlet) controls a raw material supply function and must be
off on startup.
2. The output is controlled by a threshold Embedlet monitoring the raw
material supply level.
3. The threshold embedlet is event driven and fires when the level exceeds
an upper value or drops below a lower threshold.
4. When the level is low the output should come on to start the raw material
feed. When the upper level is exceeded the output should turn off to stop
the supply.

The problem occurs when the supply is initially low and not changing because
the output is off. The threshold embedlet sees no change so the event is not
fired and the output remains off... the manufacturing process cannot start.

This is a case where reverse chain (state) logic is required. The output
must be able to 'look' back into the logical path to determine its state.

You can specifiy that every embedlet should fire its event(s) on 'start' but
that would create a chaotic, eplileptic firing of events.

This leads to a conclusion that, at least for logical Embedlets, they may
have to process both forward (event) and reverse (state) chained logic. In
addition something has to initiate the reverse logic processing such as a
timer event or the start() method in the output embedlet.

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Re: Outpost_ArchitectureDiscussionDocument_13.pdf
> Page: 12 (bottom)
>
> I'm a little concerned about allowing "device polling and timing" to be
> entirely in the domain of the embedlet service(s), if in its
> domain at all.
>
> I think it would be better if the embedlet service(s) *requested* specific
> polling "properties" from the JAPL, however polling is something
> that can be
> device and processor dependant (sometimes in the extreme).
>
> A processor or JAPL implementation should be allowed to define it's own
> polling rates etc... for instance, most temperature sensors
> require quite a
> bit of time to show any significant changes... the JAPL
> implementation will
> know how fast a device responds, and can tailor itself accordingly.
>
> I think what might be a slightly better approach (though I have
> not entirely
> thought it through) is if the embedlet service(s) could tell a
> JAPL impl. to
> notify it through an event when a change occurred... so for
> instance in the
> Temperature sensor example, the embedlet container would be able
> to give the
> sensor a change window, and receive an event when the actual JAPL
> implementation determined that it was warranted.
>
> In the case where the state of the peripheral was requested from
> the remote
> system, it would be a fairly simple task for the outpost module
> to store the
> last state and return that. Some devices of course should not be event
> driven, but most I can think of off the top of my head would best be
> implemented that way.
>
> What this means, is that the embedlet service(s) have no control over the
> polling or timing rates etc... which is the opposite of the current spec.
> discussion (and why I bring it up).
>
> Thoughts?
>
> - Brill Pappin
>   Rogue Robotics
>   www.roguerobotics.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

[Embedlets-dev] [Marketing] Embedlets and the Innovator's Dilemma....

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

Found an interesting piece which proposes that some of Ant's popularity stems from the 
Innovator's Dilemma at work:

   http://www.zanthan.com/itymbi/archives/000037.html

Worth a quick read (as is the Innovator's Dilemma, for those that have not read it).

In our discussions on how to "market" Embedlets, there have been a number of lurking 
assumptions:

1) That it will tackle (and transform) the current embedded sw development market.

I'm not sure this is the case, at least not at first....it is probably more likely that Embedlets 
will spawn new market opportunities that we haven't even forseen (like the integration with 
server side systems in the "real time" enterprise, a market that doesn't really exist yet).  In 
the longer term, it could well impact existing embedded markets, but that is not necessarily 
where the initial opportunities will be found.

2) Embedlets need to provide a "better mousetrap" (eg. more power, features, productivity, 
etc.) than existing technologies (Asm/C).  

Again, this need not be the case.  Typical of "disruptive technologies" (as defined in the 
Innovator's Dilemma), they are usually technologically simpler, and built from pre-existing 
components/technologies (which would seem to be characteristic of embedlets....we're not 
really inventing anything new....just re-packaging known techniques and best practices for 
the embedded space).  It could well be that the "value" of embedlets will be measured by 
some other metrics in initial markets that do not compete with the traditional embedded 
space.  In fact, embedlet technology might even foster the creation of such new application 
markets.  This leads me to believe that a focus on simplicity (in the early stages) will be vital.

3) We need to design the best spec/container humanly possible (out of the gate).

This is probably not a rational goal.  Sure, we should use best practices and do a good job.  
But more than that, we need to focus not so much on getting it perfect the first go round, as 
on making it very flexible and evolvable so that we can "jump on" opportunities/requirements 
(and markets) as we discover them.

4) The corollary of the prior point is that we need to determine the target "market" early on.

Again, it's very possible (if embedlets become a "disruptive technology" in the embedded 
space), that the initial adopters of this technology are not even known to us right now.  So 
the process needs to focus on "learning".  Discovering what the initial market segments 
actually will be (not what we think or hope they will be), once we have some initial 
deliverables to use in the marketing efforts.

Anyway....some thoughts on marketing and the like.



...Andrzej

Chaeron Corporation
http://www.chaeron.com

Re: [Embedlets-dev] [Forrest] Linking to a .pdf file

[Nicola K. B. <nic...@ap...>]

Ted Kosan wrote, On 16/02/2003 11.10:
...
> 
> I have placed the .pdf file into the src/documentation/resources/pdfs directory
> but when I build the site, Forrest process this .pdf file instead of just
> copying it unaltered into the build/site/pdfs directory.
> 
> Do you have any suggestions on how I can get the .pdf file to be copied
> unaltered into the build/site/pdfs directory?

The files to be copied unaltered should go under 
./src/documentation/content/**
(or wherever that dir is if you changed settings for it in 
forrest.properties)

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

[Embedlets-dev] [Security] The Importance of Authentication

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

From the latest issue of Crypto-Gram, Bruce Schneier's security newsletter (full newsletter 
available at: http://www.counterpane.com/crypto-gram-0302.html ).  It seemed relevant to 
our recent security discussion, so I've quote the pertinent stuff here.

> Authentication is more important than encryption. Most people's
> security intuition says exactly the opposite, but it's true. Imagine a
> situation where Alice and Bob are using a secure communications channel
> to exchange data. Consider how much damage an eavesdropper could do if
> she could read all the traffic. Then think about how much damage Eve
> could do if she could modify the data being exchanged. In most
> situations, modifying data is a devastating attack, and does far more
> damage than merely reading it. 

> Here's another example: a Storage Area Network over IP within a
> corporate LAN. Eavesdropping on traffic is passive, and doesn't
> necessarily expose private data (particularly on a switched network).
> But a lack of authentication allows sector-level data tampering that
> was never possible with direct-attached storage. Adding authentication
> avoids that problem entirely. 

> Or consider your own personal computer. Because data isn't
> authenticated, you are much more likely to be the victim of viruses,
> Trojans, and malware. Encryption is important; authentication is more
> important. If your computer is controlled by someone on the other end
> of a Trojan, it doesn't really matter what kind of encryption you've
> implemented. 

> Of course any secure system should have both encryption and
> authentication, but to the novice, per-packet authentication seems
> like a painful and superfluous overhead. Again and again I see
> protocols designed by otherwise-intelligent committees that mandate
> encryption but not authentication: WEP, Bluetooth, etc. An early
> version of the IPsec standard had a mode that encrypted but did not
> authenticate. 

> Last year I had a conversation with an engineer involved with security
> for the Bluetooth wireless protocol. I told him that Bluetooth has
> only privacy and not per-packet authentication. He responded with the
> prototypical lame responses: 1) pseudorandom frequency hopping makes
> it "nearly impossible" for an attacker to get in, and 2) the range is
> only 8 feet, so the attacks are naturally limited. 
 
> I tried to argue the point, but eventually gave up. Then I said
> something like: "I can hardly wait for Bluetooth to become universal,
> because I really want a wireless keyboard and mouse with the "base
> station" built into my computer." He said: "Yes, but you really
> probably don't want to use Bluetooth for that, because then somebody
> could stuff keystrokes or mouse clicks into your system." I didn't
> know whether to laugh or cry. Talk about not getting it. 


...Andrzej

Chaeron Corporation
http://www.chaeron.com

[Embedlets-dev] [Forrest] Linking to a .pdf file

[Ted K. <tk...@ya...>]

Nicola,

I have a Forrest question for you.  I am in the process of putting together a
Forrest based Embedlets website and I would like to link to the .pdf
Architecture Discussion document directly from the site navigation tab.  Here
is the section of the site.xml file which contains the href to the .pdf file:


<site label="Embedlets" href="" xmlns="http://apache.org/forrest/linkmap/1.0">

  <about label="About">
    <index label="Index" href="index.html"/>
    <specification label="Draft Embedlets spec"
href="pdfs/Outpost_ArchitectureDiscussionDocument_13.pdf">
    </specification>
    <japl label="JAPL" href="ihtml-sample.html"/>
    <outpost label="Outpost" href="ihtml-sample.html"/>
    <target_embedded_systems label="Target systems" href="ihtml-sample.html"/>
    <graphic_wiring_tool label="Graphic wiring tool" href="ehtml-sample.html"/>
    <development_site label="Development site" href="" />
    <development_list label="Development list" href=""/>
    <embedded_enterprise_list label="Embedterprise list" href="" />
    <faq label="FAQs" href="faq.html"/>
  </about>
[snip]


I have placed the .pdf file into the src/documentation/resources/pdfs directory
but when I build the site, Forrest process this .pdf file instead of just
copying it unaltered into the build/site/pdfs directory.

Do you have any suggestions on how I can get the .pdf file to be copied
unaltered into the build/site/pdfs directory?


Thanks!

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

RE: [Embedlets-dev] Re: JStamp vs TINI bytecode execution speed?

[Christopher S. <cs...@oo...>]

Systronix has a feature comparison chart as well:

http://jstik.systronix.com/compare.htm

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris pointed me to James' uVM benchmarks on the JStamp list (now why
> didn't I remember to look there?).
>
> From a quick review of James's testing it looks like a TINI is
> from 15-20 times
> slower than a JStamp.
>
> This means that a TINI will be running around 150-200K bytecodes per
> second, as compared to the 3M that a JStamp can do, and 15M for a JStik.
> What's interesting is that uVM is is about 1/2 the speed of a
> JStamp (for the
> 20mhz PIC) or about the same (for the 40mhz PIC chip).
>
> Granted, these tests were simple ones that would not reflect a
> "real world" mix
> of bytecodes being executed, but their probably close enough.
>
> What is intriguing is that according to the above, the TINI will
> be the least
> capable target platform (based on processor speed alone and ignoring JVM
> features and memory) that we are considering.  Bit of a
> revelation for me,
> since I had just assumed that the PIC's running uVM would take
> that position.
> Goes to show you....always check your assumptions.
>
> Kind of leads me to believe if we can implement Embedlets on a
> TINI and have
> enough horsepower to do some "useful" applications on that
> platform, then the
> rest will be no problem.
>
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.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
>

[Embedlets-dev] Re: JStamp vs TINI bytecode execution speed?

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

Chris pointed me to James' uVM benchmarks on the JStamp list (now why 
didn't I remember to look there?).

From a quick review of James's testing it looks like a TINI is from 15-20 times 
slower than a JStamp.

This means that a TINI will be running around 150-200K bytecodes per 
second, as compared to the 3M that a JStamp can do, and 15M for a JStik.  
What's interesting is that uVM is is about 1/2 the speed of a JStamp (for the 
20mhz PIC) or about the same (for the 40mhz PIC chip).  

Granted, these tests were simple ones that would not reflect a "real world" mix 
of bytecodes being executed, but their probably close enough.

What is intriguing is that according to the above, the TINI will be the least 
capable target platform (based on processor speed alone and ignoring JVM 
features and memory) that we are considering.  Bit of a revelation for me, 
since I had just assumed that the PIC's running uVM would take that position. 
Goes to show you....always check your assumptions.

Kind of leads me to believe if we can implement Embedlets on a TINI and have 
enough horsepower to do some "useful" applications on that platform, then the 
rest will be no problem.



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

[Embedlets-dev] [Arch] re; Device polling

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

Chris responds to Brill:

> This is the classical 'who has control' discussion that goes on in any
> architecture. My recomendation would be to break the pieces down to a
> little lower level so that you have fine-grain, descrete functional blocks
> that can provide both functional requirements:

> This also gives you the flexibility to have local independent loops that
> run at different rates if that is a requirement. You (the Embedlet user)
> gets to determine who is in control! You (the Embedlet designer) do no
> have to accommodate multiple, mutually exclusive requirements.

I have to side with Chris on this.  Creating a JAPL interface layer that does 
device-level protocol neutralization and provides a solid generic interface to 
arbitrary devices is challenging enough.  Then there will be the task of 
providing JAPL interfaces for the large quantity of unique hardware devices 
out there.  KISS principle would seem to be a wise way to go for the JAPL 
layer, just due to the size of the core task.

If you try to subsume things like polling timer services (which will drag event 
management and a lot of the rest) into the device interface layer, it will 
complicate that layer immensely and result in too much coupling between the 
device and application (Embedlet) code.  Embedlets are the natural place for 
that kind of service, would provide a clean split of responsibility.

Let JAPL expose a common device interface.  But let the Embedlets determine 
how/when that interface should be invoked. Clean....simple...decoupled.  

This approach has some other key benefits.  JAPL interfaces stay simple and 
could be used by other embedded Java solutions (for example, hardcoded 
solutions that don't use an Embedlet container).  It also allows Embedlets to 
use non-JAPL enabled devices easily, yet still leverage common services like 
Timer/Events as needed.  Embedlets will also be configured using XML 
syntax, so that is a logical place to put things like timing requirements (how 
often to poll a device).  Keep in mind that Timers will also be used for other 
purposes (eg. sending a status update to a remote enterprise system on a 
periodic basis, Management services, etc), not just for device polling.

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

RE: [Embedlets-dev] Device polling

[Christopher S. <cs...@oo...>]

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Re: Outpost_ArchitectureDiscussionDocument_13.pdf
> Page: 12 (bottom)
Bill states:

>Some devices of course should not be event
> driven, but most I can think of off the top of my head would best be
> implemented that way.

Logical functions are by nature state and not event driven. You can make
them event driven by performing the logical function in response to a
change, however this leads to initial state problems and race conditions. Or
you can use a timer to issue an event that causes the logical deveices to
poll their state and assert some output. Complex systems are usually a mix
of state (polled) and event driven components.

My previous post addresses this by providing the best of both.

[Embedlets-dev] Re: Licenses...

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

Nicola clarifies:

> Not really. Simply substitute "Apache" with the name of the copyright
> holder and the name of the project, and it's usable.
> 
> example: http://www.krysalis.org/license.html

I think this makes a lot of sense......let's use the Apache license boilerplate, 
and just change the terms to refer to our project/copyright holders.  It would 
seen to meet our needs the best, and most seem to like that license.

> But you must start first here and start growing. When there will be a
> community working on code and some initial implementations, it can be
> discussed.

I agree.....it think it's premature to approach Apache at the moment.  Let's wait 
a month or two (I doubt it will be longer than that) and have something more 
substantial to show (eg. Spec v 1.0, interface definitions, and parts of a 
container ref impl).  Then we can revisit the idea of approaching Apache.

> There is some level of politics at Apache.

I think we also need to get just a touch further down the road before we open 
the floodgates and attract the level of attention that Apache partnership would 
bring.  A small tight group is more likely to produce a good Version 1.0 
spec/impl faster than a larger group.  Think of what the embedlets discussions 
were like if we had 100 instead of a half dozen active participants.  We need to 
move fast right now to get the germ sprouted and rolling in the right direction, 
and a small tight team has a chance of pulling that off. Once the directions and 
spec are solid, then it's less likely that larger participation will slow things down 
or change the direction.  

> If you all want, I can ask informally some people there what they would
> think about it. Let's see what others think.

I think it would be better if we had more than just an "idea" before we approach 
Apache, even informally.


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

[Embedlets-dev] [GW] Similar tool...

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

Thought this might give those looking at the Graphical Wiring tool some ideas:

http://www.scioworks.com/scioworks_camino.html

It's a Visual Modelling/Code Generation tool for the Struts framework. Worth a 
look to see what ideas might be worth considering.


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

RE: [Embedlets-dev] Device polling

[Christopher S. <cs...@oo...>]

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Re: Outpost_ArchitectureDiscussionDocument_13.pdf
> Page: 12 (bottom)
>
> I'm a little concerned about allowing "device polling and timing" to be
> entirely in the domain of the embedlet service(s), if in its
> domain at all.
>
> I think it would be better if the embedlet service(s) *requested* specific
> polling "properties" from the JAPL, however polling is something
> that can be
> device and processor dependant (sometimes in the extreme).
>
> A processor or JAPL implementation should be allowed to define it's own
> polling rates etc... for instance, most temperature sensors
> require quite a
> bit of time to show any significant changes... the JAPL
> implementation will
> know how fast a device responds, and can tailor itself accordingly.
>
> I think what might be a slightly better approach (though I have
> not entirely
> thought it through) is if the embedlet service(s) could tell a
> JAPL impl. to
> notify it through an event when a change occurred... so for
> instance in the
> Temperature sensor example, the embedlet container would be able
> to give the
> sensor a change window, and receive an event when the actual JAPL
> implementation determined that it was warranted.
>


> In the case where the state of the peripheral was requested from
> the remote
> system, it would be a fairly simple task for the outpost module
> to store the
> last state and return that. Some devices of course should not be event
> driven, but most I can think of off the top of my head would best be
> implemented that way.
>
> What this means, is that the embedlet service(s) have no control over the
> polling or timing rates etc... which is the opposite of the current spec.
> discussion (and why I bring it up).
>
> Thoughts?
This is the classical 'who has control' discussion that goes on in any
architecture. My recomendation would be to break the pieces down to a little
lower level so that you have fine-grain, descrete functional blocks that can
provide both functional requirements:

1. A sample timer (Embedlet) that issues timer events
1. I/O (JAPL or Embedlet) that just gets the data when told. Then issues a
'done' event
3. A theshold sensor that receives the 'done' event checks upper/lower
bounds and issues an 'out-of-bounds' event.

In this way the system can be built up from mix-and-match components that
may come from different vendors and no one component has disproportionate
'control'.

This also gives you the flexibility to have local independent loops that run
at different rates if that is a requirement. You (the Embedlet user) gets to
determine who is in control! You (the Embedlet designer) do no have to
accommodate multiple, mutually exclusive requirements.

>
> - Brill Pappin
>   Rogue Robotics
>   www.roguerobotics.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

[Embedlets-dev] Device polling

[Brill P. <bri...@ro...>]

Re: Outpost_ArchitectureDiscussionDocument_13.pdf
Page: 12 (bottom)

I'm a little concerned about allowing "device polling and timing" to be
entirely in the domain of the embedlet service(s), if in its domain at all.

I think it would be better if the embedlet service(s) *requested* specific
polling "properties" from the JAPL, however polling is something that can be
device and processor dependant (sometimes in the extreme).

A processor or JAPL implementation should be allowed to define it's own
polling rates etc... for instance, most temperature sensors require quite a
bit of time to show any significant changes... the JAPL implementation will
know how fast a device responds, and can tailor itself accordingly.

I think what might be a slightly better approach (though I have not entirely
thought it through) is if the embedlet service(s) could tell a JAPL impl. to
notify it through an event when a change occurred... so for instance in the
Temperature sensor example, the embedlet container would be able to give the
sensor a change window, and receive an event when the actual JAPL
implementation determined that it was warranted.

In the case where the state of the peripheral was requested from the remote
system, it would be a fairly simple task for the outpost module to store the
last state and return that. Some devices of course should not be event
driven, but most I can think of off the top of my head would best be
implemented that way.

What this means, is that the embedlet service(s) have no control over the
polling or timing rates etc... which is the opposite of the current spec.
discussion (and why I bring it up).

Thoughts?

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com

Re: [Embedlets-dev] Re: [Mgmt] License?

[Nicola K. B. <nic...@ap...>]

Ted Kosan wrote, On 14/02/2003 0.19:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> Andrzej,
> 
> 
>>But before I can really make any progress, we need to decide 
>>what kind of license we want to release this stuff under:
>>
>>Apache? 
>>GPL?
>>LGPL?
>>Some other?
> 
> 
> Sourceforge requires that a new project select (at least tentatively) an open
> source license as part of the registration process.
> 
> http://opensource.org/licenses/
> 
> 
> I spent a number of hours studying these licenses and the one I liked the most
> was the Apache license:
> 
> http://www.opensource.org/licenses/apachepl.php
> 
> 
> However, since only Apache projects can use this license

Not really. Simply substitute "Apache" with the name of the copyright 
holder and the name of the project, and it's usable.

example: http://www.krysalis.org/license.html

>  I then looked for the
> license that was as close to it as possible and the one I selected was the BSD
> license:
> 
> http://www.opensource.org/licenses/bsd-license.php
> 
> We are not locked into the BSD license, though,  and we can change it at any
> time.  I figured that we would get around to addressing this issue eventually.
> 
>>It would also be nice to become an "official" Apache project 
>>some time down the road....lots of benefits to going that 
>>route, and if we use the Apache license terms in the beginning 
>>this would be easier.
> 
> [...]
> 
>>One issue is how to attribute the copyright since we don't 
>>have a legal entity like the Apache Foundation or embedlets.org 
>>that can legally own the copyright.
> 
> 
> After Nicola had posted some links to information on the Apache Incubator site
> I spent some time studying the rest of the Incubator materials along with the
> Apache foundation's overall philosophies and goals.
> 
> Now that you have mentioned the possibility of the Embedlets project putting
> together a proposal to become part of the Apache foundation I have started to
> think about this.
> 
> The Apache foundation appears to be primarily focused on server side open
> source software development.  However, if the prediction of billions of
> embedded systems being attached to the internet in the near future comes true
> (which seems likely) then enterprise systems are going to have a need for
> technologies that allow them to monitor, control and manage these devices.
> 
> Embedlets, and especially the Outpost reference implementation, are being
> specifically designed to provide this type of technology.   When viewed from
> this perspective it appears that the Embedlets/Outpost project has the
> potential of bringing capabilities to the Apache Foundation that it does not
> currently have and that would be very complementary to their existing project
> base.
> 
> As for the benefits of what Apache would provide for the Embedlets/Outpost
> project, more direct access to cutting edge back end developers,  increased
> visibility and the support of a best-practice open source community are just a
> few of these.
> 
> The more I think about this idea the more I like it.  A main question I have,
> though, is if Apache would be interested in bringing an embedded systems
> oriented project into their community?

My personal opinion? Yes. It just makes sense.
But you must start first here and start growing. When there will be a 
community working on code and some initial implementations, it can be 
discussed.

There is some level of politics at Apache. So some think that GUI 
projects can come into Apache, some think no, they are not server-side.

Embedlets are more server-side, so it would be easier, but I would 
approach Apache with some working stuff.

If you all want, I can ask informally some people there what they would 
think about it. Let's see what others think.

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [Embedlets-dev] License?

[Nicola K. B. <nic...@ap...>]

Andrzej Jan Taramina wrote, On 13/02/2003 18.31:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> OK...I'm hammering out some preliminary interfaces and base classes to get 
> us going.
> 
> But before I can really make any progress, we need to decide what kind of 
> license we want to release this stuff under:
> 
> Apache? 
> GPL?
> LGPL?
> Some other?

I'd like to chime in and post my 2c. I'm an Apache member, but also the 
founder of krysalis.org, that wants to start living soon with its own 
legal identity.

> So that the appropriate header comments will go in each source file, and the 
> correct license.txt file will be included.
> 
> The Apache license lets anyone do what they want, so long as they include 
> the license terms, copyright and acknowledgement to the embedlets.org 
> group...so it's pretty flexible.  I'm leaning towards this one.  

Yes, of course I like the Apache license. "Do what you want but give us 
credit, don't misuse our name, and don't sue us". It's real total 
freedom. It's the best license to make software used by all and become a 
reference.

> It would also be 
> nice to become an "official" Apache project some time down the road....lots of 
> benefits to going that route, and if we use the Apache license terms in the 
> beginning this would be easier.

Definately. Changing a license in case of individual contributors would 
require all to sign for the change. It becomes easily a mess. See 
below... [1]

> GPL is nice, but it forces all other implementations to be open source as well 
> (it's viral in that regard). 

The virality of GPL makes it difficult if not impossible to use for 
systems that want to become industry standards.

> LGPL is more for libraries than containers so 
> probably doesn't fit well.

And it doens't work well with Java. It defines "linking", which in Java 
is not present. At Apache it's not possible to put LGPL stuff in CVS, 
because we think it's as viral as GPL. We have asked clarifications to 
FSF but have not gotten them yet it seems.

> One issue is how to attribute the copyright since we don't have a legal entity 
> like the Apache Foundation or embedlets.org that can legally own the 
> copyright.

[1] From my experience I can say that making a legal entity that has the 
license is the best solution in this case. It makes it easy to change 
the license in the future or give away copyright, as for example would 
happen by donating code to Apache.

I am in the process of doing it for Krysalis for the same reason.

Anyway, I am also part of the Incubator PMC at Apache 
http://incubator.apache.org/ ... so if/when you will apply for Apache 
you will see me there too ;-)

 From what I see this is an excellent group, if you continue like this 
IMHO you will go far. My compliments :-)

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

[Embedlets-dev] Re: [Mgmt] License?

[Ted K. <tk...@ya...>]

Andrzej,

> But before I can really make any progress, we need to decide 
> what kind of license we want to release this stuff under:
> 
> Apache? 
> GPL?
> LGPL?
> Some other?

Sourceforge requires that a new project select (at least tentatively) an open
source license as part of the registration process.

http://opensource.org/licenses/


I spent a number of hours studying these licenses and the one I liked the most
was the Apache license:

http://www.opensource.org/licenses/apachepl.php


However, since only Apache projects can use this license I then looked for the
license that was as close to it as possible and the one I selected was the BSD
license:

http://www.opensource.org/licenses/bsd-license.php


We are not locked into the BSD license, though,  and we can change it at any
time.  I figured that we would get around to addressing this issue eventually.



>It would also be nice to become an "official" Apache project 
>some time down the road....lots of benefits to going that 
>route, and if we use the Apache license terms in the beginning 
>this would be easier.
[...]
>One issue is how to attribute the copyright since we don't 
>have a legal entity like the Apache Foundation or embedlets.org 
>that can legally own the copyright.

After Nicola had posted some links to information on the Apache Incubator site
I spent some time studying the rest of the Incubator materials along with the
Apache foundation's overall philosophies and goals.

Now that you have mentioned the possibility of the Embedlets project putting
together a proposal to become part of the Apache foundation I have started to
think about this.

The Apache foundation appears to be primarily focused on server side open
source software development.  However, if the prediction of billions of
embedded systems being attached to the internet in the near future comes true
(which seems likely) then enterprise systems are going to have a need for
technologies that allow them to monitor, control and manage these devices.

Embedlets, and especially the Outpost reference implementation, are being
specifically designed to provide this type of technology.   When viewed from
this perspective it appears that the Embedlets/Outpost project has the
potential of bringing capabilities to the Apache Foundation that it does not
currently have and that would be very complementary to their existing project
base.

As for the benefits of what Apache would provide for the Embedlets/Outpost
project, more direct access to cutting edge back end developers,  increased
visibility and the support of a best-practice open source community are just a
few of these.

The more I think about this idea the more I like it.  A main question I have,
though, is if Apache would be interested in bringing an embedded systems
oriented project into their community?


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Re: [Embedlets-dev] Some good reading....

[Gregg W. <ge...@co...>]

Andrzej Jan Taramina wrote:
> eWeek Article at:
> 
>    http://www.eweek.com/article2/0,3959,857161,00.asp

Since ethernet is a CSMA (carrier sense, multiple access) technology, it
can never be 'instanteous' or 'hard real-time'.  However, many
controllers are becoming smarter and manufactures are also able to put
more control at the controllers instead of at the administrative level. 
It will be interesting to see what happens here.  I suspect that a new
family of devices will evolve due to reduced cost of processing power,
and the need to remove realtime control from the comms link...

> And another one on Motorola using Linux and Java on their newest cell
> phones:
> 
>    http://news.com.com/2100-1001-984424.htm

this should be 

	http://news.com.com/2100-1001-984424.html

Reading it now...

Gregg

Re: [Embedlets-dev] License?

[Gregg G. W. <gr...@sk...>]

>But before I can really make any progress, we need to decide what kind of 
>license we want to release this stuff under:
>
>Apache? 

+1

Forming a non-profit organization before releasing any code would be the best 
bet to maintain sometime of group ownership.  Individual authors could own 
their own code as long as their license was compatible with apache...  This is 
where things start to get sticky and political :-|

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-dev] License?

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

OK...I'm hammering out some preliminary interfaces and base classes to get 
us going.

But before I can really make any progress, we need to decide what kind of 
license we want to release this stuff under:

Apache? 
GPL?
LGPL?
Some other?

So that the appropriate header comments will go in each source file, and the 
correct license.txt file will be included.

The Apache license lets anyone do what they want, so long as they include 
the license terms, copyright and acknowledgement to the embedlets.org 
group...so it's pretty flexible.  I'm leaning towards this one.  It would also be 
nice to become an "official" Apache project some time down the road....lots of 
benefits to going that route, and if we use the Apache license terms in the 
beginning this would be easier.

GPL is nice, but it forces all other implementations to be open source as well 
(it's viral in that regard).  LGPL is more for libraries than containers so 
probably doesn't fit well.

One issue is how to attribute the copyright since we don't have a legal entity 
like the Apache Foundation or embedlets.org that can legally own the 
copyright.



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

[Embedlets-dev] Some good reading....

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

From eWeek, an article on the growing use of Ethernet on the factory floor.  
Definitely worth a read.  Here's a quote from the piece:

> One of the obstacles to Ethernet's acceptance at the device level is
> the lack of standards at the application level. 

> "We decided not to use Ethernet at the I/O [device] level. There is no
> real standard yet. You can't take a GE Ethernet controller and hook it
> up to someone else's device," said Jan Lindstrom, vice president of
> technology for printing press manufacturer KBA North America Inc., in
> York, Pa. 

eWeek Article at:

   http://www.eweek.com/article2/0,3959,857161,00.asp

And another one on Motorola using Linux and Java on their newest cell 
phones:

   http://news.com.com/2100-1001-984424.htm

An interesting strategy from Motorola that may presage what could happen on 
the shop/warehouse floor.

Both pieces point to potentially large and valuable market opportunities for 
Outpost and Embedlets.

BTW....I think it's time for me to post something controversial again.....the list 
has been too quiet!  Good thing too.....given me some uninterrupted "think 
time" about the spec and details of the architectural implementation. <grins>  
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Embedlets-dev] Bouncy Castle Crypto....

[Brill P. <bri...@ro...>]

Yes, that was why I suggested that I might have found a solution... I'll
look at using it when I have a moment...

I'm doing crazy 14 hour days this week, so I'll have to catch up on the rest
of the list on the weekend... talk to you all then.

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com


----- Original Message -----
From: "Andrzej Jan Taramina" <an...@ch...>
To: <emb...@li...>
Sent: Wednesday, February 12, 2003 1:24 PM
Subject: [Embedlets-dev] Bouncy Castle Crypto....


> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> ...just a little addendum:  I noticed that it is said to work with
J2ME....so it
> seems likely that we could use it in those situations where absolute
security is
> required.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.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
>

[Embedlets-dev] Bouncy Castle Crypto....

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

...just a little addendum:  I noticed that it is said to work with J2ME....so it 
seems likely that we could use it in those situations where absolute security is 
required.

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

[Embedlets-dev] Encryption for Embedlets....

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

Just spotted this announcement:

> The Legion of the Bouncy Castle (http://www.bouncycastle.org/) has
> released > version 1.18 of the Bouncy Castle Java Cryptography API, an
> open source, clean-room implementation of the Java Cryptography
> Extension (JCE). It supports X.509 certificates, PKCS12, S/MIME, CMS,
> PKCS7, and lots of other juicy acronyms. It also includes its own
> light-weight crypto API that works in Java 1.0 and later, and does not
> depend on the JCE. Version 1.18 is mostly a bug fix release. 

If it can be configured to use only it's own lightweight crypto API and since it 
works on older Java releases, it might have some applicability to use with 
Embedlets.

Anyone care to investigate this?


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