embedlets-developer — Outpost Embedlet container developer list

[Embedlets-developer] Re: General event mechanism

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

Andrzej,

>Where is the info/discussions on these interfaces?  I
wanted to review that 
before I post some thoughts to the Embedlet list...

Well, after I realized that people were probably somewhat
busy getting into the new year I posted the 'Embedlet
Challenge' idea so that I could start exploring Embedlets
from the perspective of the wiring tool.  I think that the
discussion about the interfaces we are looking for will
probably start right now.

I have been using the Elevator challenge to explore how
various interface ideas play inside of a graphical wiring
tool mockup that I threw together (for now I am just
focusing on the event mechanism).  Over the weekend I came
to the conclusion that the SignalSender and SignalReceiver
interfaces would need to be made more general.  

I looked through the Embedlet traffic we generated on the
JStamp list and actually I found a post or two from you
that talked about a very general Event mechanism.  At that
time I did not have a good feel for why a general event
mechanism was superior to a more tailored Event mechanism
(like what is present in AWT) but after playing with the
wiring tool mockup for the past couple of weeks I think I
understand this better now.

So, here is what the SignalSender/SenderReceiver event idea
evolved into:


public interface EventSender
{
  add(type of operation)Receiver(EventReceiver er);
  remove(type of operation)Receiver(EventReceiver er);
  EventReceiver[] get(type of operation)Receivers(); //get
the receivers for a specific type.
  EventReceiver[] getAllReceivers(); //get a list of all
receivers 

  set(type of operation)Properties    //Temporal
properties, etc.
  get(type of operation)Properties
}

public interface EventReceiver //All Embedlets implement
this interface.
{
   receiveEmbedletEvent(EmbedletEvent ee);
}


For the Elevator Embedlet the following EventReceiver
registration methods might be present:

addFloorReceiver(EmbedletReceiver er); //For receiving
Floor events like 'SetDirectionLights' and
'SetCurrentFloorDisplay'.

addShaftReceiver(EmbedletReciever er); //For receiving
Shaft events like 'MoveElevator'.



The main way that a general event mechanism seems to differ
from a more specific event mechanism like AWT's is that the
type of 'Listener' passed into an AWT addXXXListener method
is Listener type specific while the 'Listener' (Receiver)
in a more general mechanism uses a single type of listener
(in this case org.embedlet.EvenReceiver).


It also appears to me that, in a general event system, the
type of the Event is used to indicate what to do with the
event.  For example, if all Embedlet events inherit from
EmbedletEvent then the Elevator Embedlet can send
FloorEvents through the general event mechanism to
controllers that are responsible for running each floor and
ShaftEvents to the controller's that are responsible for
running each elevator shaft, etc.

Different EmbedletEvent types are created to handle all
event needs.


Are these the kind of ideas you were referring to when you
talked about a 'general event mechanism'?


Ted


--- Andrzej Jan Taramina <an...@ch...> wrote:
> Ted:
> 
> > So far the 6 interfaces I started with have been
> reduced to
> > the following 2:
> > 
> > SignalSender and SignalReceiver
> 
> Where is the info/discussions on these interfaces?  I
> wanted to review that 
> before I post some thoughts to the Embedlet list.....
> 
> 
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: Elevator Challenge update

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

Gregg,

>>SignalSender and SignalReceiver
>
>This makes the term protocol neutralizer even more 
>appropriate.  The protocol agnostic nature of those names 
>is very revealing...

Of all the Embedlet related traffic that was generated on
the JStamp list, the concept of a 'protocol neutralizer'
stuck in my mind as being one of the more important ideas. 
At least for me, it has heavily influenced my thinking
about what an Embedlet container should be and so far the
concept has helped with discovering appropriate interfaces
for it.

The 1.5 months of brainstorming we did on Embedlets on the
JStamp list is proving to be a rich source of useful ideas.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-developer] Elevator Challenge update

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

>So far the 6 interfaces I started with have been reduced to
>the following 2:
>
>SignalSender and SignalReceiver
>
>and all signal customization is handled through subclasses
>of a main SignalEvent class.

This makes the term protocol neutralizer even more appropriate.  The protocol 
agnostic nature of those names is very revealing...

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

[Embedlets-developer] Embedlets related traffic on Cork list

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

I just wanted to let people know that if the Embedlets list
seemed kind of quiet during the past week or so it is
because we have been generating a great deal of list
traffic on the Cork developer list
(http://sourceforge.net/projects/cork) about what kind of a
Cork API an Embedlet Container that is being graphically
configured would most like to see.

If you are interested in how an Embedlet Container might
best be integrated with the Cork platform-independent
device driver project, please feel free to join us on the
Cork list.

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Elevator Challenge update

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

The Elevator Challenge has turned out to be an excellent
application for discovering how Embedlets might work in
practice.  Also, solving this challenge using a visual
mockup of what the Graphical Wiring Tool might look like
was definitely a good strategy.

So far the 6 interfaces I started with have been reduced to
the following 2:

SignalSender and SignalReceiver

and all signal customization is handled through subclasses
of a main SignalEvent class.


The solution has also become distributed across a main
controller Embedlet Container (located in a machine room),
an Embedlet Container on each floor and an Embedlet
Container in each elevator (I actually expanded the scope
of the challenge to accommodate multiple elevator shafts).

So far the main keys that have enabled a solution to move
forward are the following:

1) Limit all inter Embedlet/Peripheral/Proxy communications
to using the SignalSender and SignalReceiver interfaces.

2) Encapsulating all elevator logic in one Elevator Logic
Embedlet that can be visually configured for the number of
floors and the number of shafts it must accommodate.  After
one makes the assumption that a single Embedlet contains
all the logic needed to accommodate up to an 100 floor
building with up to 10 elevator shafts then how this logic
is implemented is no longer a concern (although there is a
good chance that it is internally implemented in Java).

As soon as the system's main logic was encapsulated inside
of one Component then the primary work involved with
creating a solution shifted to graphically wiring all of
the system's I/O signals into the Elevator Logic Embedlet.

3) Enabling communications between remote Embedlet
containers.  This had the effect of taking the fairly nasty
problem of figuring out how to route the signals from 10
floors and 2 elevators into the main controller.  Building
remote Embedlet Container communications into the mockup
allowed the solution for 1 floor's communications to be
enumerated across the other 9 floors almost effortlessly.



Finally,  these are my impressions so far of graphically
wiring together an embedded system using Embedlets:

1) It looks like it is going to work.  We should be able to
judge this better a few days from now, though, so lets not
get our hopes up.

2) It 'feels' like it might be an order of magnitude more
productive (no kidding) than current embedded technologies.
 I think that this means that embedded solutions could be
developed in an order of magnitude less time or that an
order of magnitude larger system could be developed in the
same time.  

If the following were true:

a) prebuilt software components were available that
encapsulated the 'heavy lifting' logic parts of the
application, like the Elevator Logic Embedlet (which is one
of the primary reasons for software Components in the first
place).

b) 100% plug-and-play sensor and actuator modules were
available to handle all of the system's I/O needs.  These
modules would need to automatically appear in the graphic
wiring tool as soon as they were snapped into the system.

c) we were using Embedlet Container 1.0 level software
which already had all of the needed interfaces worked out
in a satisfactory way.

then it appears that this application could be completely
bench assembled and tested (including both software and
hardware) within 3 to 8 hours.


3)  A non programmer who understood electronic interfaces
and the Elevator problem domain should be able to wire a
solution to this problem together.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: The Great Embedlet Challenge!

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

Greg,

>This is a pretty sophisticated interface, but it 
>is where I think that this group needs to be able 
>to go.

I guess one of the great things about open development is
that the directions the solutions take are driven by those
who contribute the most to the project.

Thank you for contributing this idea and I will tackle it
as soon as I finish James' elevator challenge.


BTW, the elevator challenge is turning out to be extremely
enlightening.  It appears that a standard elevator logic
software component that can be graphically configured with
the number of floors in a building, floor sequence
algorithm, emergency behaviors, etc.is a natural idea.

A company that specializes in elevators develops a
high-quality and safety-tested configurable elevator
component like this and then sells it to elevator
manufacturers.

A heuristic that seems to be developing here is that
complex logic that is highly reusable gets programmed as a
Component by a talented Java programmer or programmers and
then this component is serialized and then published so
that application assemblers can graphically wire it into
their embedded applications.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-developer] The Great Embedlet Challenge!

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

Ted Kosan wrote:
> Just send your application challenges to the list and I
> will attempt to wire an application together using the
> (above referenced) wiring tool mockup.  Of course, I am
> free to come up with Embedlets and Proxies to help me solve
> these problems but this is one of the reasons for doing
> this exercise.

We have started to work on an interface to the TRI-PLC device at
www.triplc.com.  This device can be accessed directly, or via TCP/IP (by
connecting to a PC whose serial port is connected to the device, and it
is running the 'server').

We are creating a polling engine for access to the PLC to do data
gathering off of it.  It will continue to run as a PLC and manage
whatever it is programmed to.  What we want to do is allow a collection
of features of the PLC to be specified as the 'enterprise data', and
then a sub-collection of that collection to be specified as 'triggers'. 
So, when one of trigger conditions are met, the current values are read
(except for the trigger) and the appointed collection of data is
published to the enterprise system.

This is a pretty sophisticated interface, but it is where I think that
this group needs to be able to go.

Gregg

[Embedlets-developer] RE: The Great Embedlet Challenge!

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

James,

Thanks for taking the time to develop a challenge!  This is
a very jucy problem...

I am starting to develop the theory that 90% of all
embedded system I/O can be handled by device proxies that
implement from a selection of just 6 Java interfaces:

1) InputBit //Single bit input.

2) OutputBit //Single bit output.

3) InputBus //Parallel binary input.

4) OutputBus /Parallel binary output.

5) SignalInputStream //Analog input.

6) SignalOutputStream //Analog output.


This challenge will certainly put this theory to the test!


Ted



--- James Caska <ca...@vi...> wrote:
> Wire me up an Elevator controller
> 
> A 10 story building has two elevators. Each elevator has
> a switch for each
> level, a close and open button, a warning button, a
> sensor to detect the
> weight in the elevator, a timer for the delay until the
> door closes, a light
> and backup light from an alternative power system should
> the main power
> fail. Each floor has two buttons, an up and down which to
> indicate the
> desired direction of a travel for people waiting at the
> floor. Each elevator
> also has has a display panel to show the current level
> and the direction of
> travel.
> 
> Design a controller to control the direction of each
> elevator once the door
> closes and also a J2EE database reporting system which
> reports the average
> time a person waits after pressing their button up or
> down until the door
> opens in front of them.
> 
> Well.. you asked for it! :-)
> 
> James
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] The Great Embedlet Challenge!

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

I have been doing some more work on the Embedlet Wiring
Tool mockup that I posted to the list on Friday January
3rd:

http://embedlets.sourceforge.net/devdocs/diagrams/embedlet_pictures1.png

And the more I play with it the more I like where it is
going.

In fact, I like the mockup so much that I am challenging
everyone on the list to come up with an embedded based
application that can *not* be solved by using the graphic
wiring tool model that I have proposed.

Just send your application challenges to the list and I
will attempt to wire an application together using the
(above referenced) wiring tool mockup.  Of course, I am
free to come up with Embedlets and Proxies to help me solve
these problems but this is one of the reasons for doing
this exercise.


Here is an example challenge that has already been solved
(see the bottom of the above link for the solution):

Skeptic:  Ok, lets see you build a system that reports the
temperature on a boiler to a backend system every 10
minutes.  The temperature must be taken once every minute
and the temperature that is sent to the backend system must
be the average of 10 samples.  A Chart Recorder must also
be plugged into the embedded system so that a visual
indication of the boiler's operation can be seen by
maintenance personnel.


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-developer] replyto for embedlet list

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

>Brill,
>
>The mailman application has this to say about reply addresses:
>
>"Where are replies to list messages directed? Poster is strongly recommended
>for most mailing lists."
>
>
>Whichever way people want it set if fine with me (either reply to the list or
>reply to the Poster) so what does everyone prefer?

I'd prefer 'reply' to go to the sender, and 'reply-all' to the list...

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

Re: [Embedlets-developer] replyto for embedlet list

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

>I think the replyto for the embedlet list needs to be changed... when
>replying, I get the posters address instead of the list address.
>
>its workable, but a bit of a pain...

Since the beginning of internet lists (which started as notes and then 
usenet), reply has always gone to the poster, and reply-all to the poster and 
the list. In the past years, people have started complaining about this on 
various lists saying that they don't like that.

When I reply-all to this list, I get the -developer-admin and the -developer 
addresses, and not the poster.  The Sender: field overrides the consideration 
of From: A reply just goes to the list.  I am not sure what you are 
experiencing Brill, nor what mail client you are using. I am using MH which 
has always followed the standards...  Maybe the playing field is changing...

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

Re: [Embedlets-developer] replyto for embedlet list

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

Brill,

The mailman application has this to say about reply addresses:

"Where are replies to list messages directed? Poster is strongly recommended
for most mailing lists."


Whichever way people want it set if fine with me (either reply to the list or
reply to the Poster) so what does everyone prefer?

Ted


--- Brill Pappin <bri...@ro...> wrote:
> I think the replyto for the embedlet list needs to be changed... when
> replying, I get the posters address instead of the list address.
> 
> its workable, but a bit of a pain...
> 
> - Brill Pappin
>   Rogue Robotics
>   www.roguerobotics.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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] replyto for embedlet list

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

I think the replyto for the embedlet list needs to be changed... when
replying, I get the posters address instead of the list address.

its workable, but a bit of a pain...

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com

Re: [Embedlets-developer] Re: Avalon [from JStamp List] (from Andrzej)

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

> > I liked Avalon as well... maybe it would be possible to create an
> > "embedded" version of Avalon.. its after all simply someone else "custom
> > solution"... anyway, I think if we took Avalon and picked apart, we
could
> > come up with something with a small footprint still in the Avalon
> > pattern... the Avalon guys would likely add it to their collection if we
> > offered it.
>
> One of the key Avalon developers is already working on a small footprint,
> MIDP-capable version of the Avalon framework (ver 5.0)....I'll take a
gander
> and see what it looks like.

Cool... maybe you should invite that fellow to join this list and release
the code to us... I think he'd get a lot of useful feedback fairly quickly
as all of us start "playing" with it.

- Brill Pappin

[Embedlets-developer] Re: Avalon [from JStamp List] (from Andrzej)

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

Andrzej is in the process of getting an email problem fixed and so in the mean
time I am acting as an email proxy for him. -Ted
-----

Brill gushed:

> I liked Avalon as well... maybe it would be possible to create an
> "embedded" version of Avalon.. its after all simply someone else "custom
> solution"... anyway, I think if we took Avalon and picked apart, we could
> come up with something with a small footprint still in the Avalon
> pattern... the Avalon guys would likely add it to their collection if we
> offered it.

One of the key Avalon developers is already working on a small footprint, 
MIDP-capable version of the Avalon framework (ver 5.0)....I'll take a gander 
and see what it looks like.


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


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-developer] Avalon [from JStamp List]

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

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com

----- Original Message -----
From: "James Caska" <ca...@vi...>
To: "Brill Pappin" <bri...@ro...>
Sent: Friday, January 03, 2003 3:21 AM
Subject: RE: [Embedlets-developer] Avalon [from JStamp List]


> >*complete custom solution*
>
> There's that custom word again :-) - Don't worry brill, looks like the
> embedlets is going to be an interface specification which means all sort
of
> opportunties for 'custom' implementations of the interfaces :-)

heh... I wasn't necisarily saying thats what we needed, but thet we could
have done it ;)

> Actually the more I think about Avalon, the more I like it from the Server
> Side implementation of the embedlets point of view, and it even makes
sense
> for a distributed computing version of Avalon ie, take Avalon and execute
it
> over hundreds of embedded devices, BUT!, I re-iterate that it should not
be
> mandatory for every embeddlet remote platform to be avalon-embedlet
capable.

I liked Avalon as well... maybe it would be possible to create an "embedded"
version of Avalon.. its after all simply someone else "custom solution"...
anyway, I think if we took Avalon and picked apart, we could come up with
something with a small footprint still in the Avalon pattern... the Avalon
guys would likely add it to their collection if we offered it.

- Brill Pappin

[Embedlets-developer] Avalon inspired interface hunting

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

I spent a significant amount of time on the Avalon site yesterday and the
container design ideas there are absolutely fabulous!   So far I am aware of
the following 4 containers that we might be able to gain some insight from for
designing an Embedlet container: The EJB container, the Servlet container, the
BeanContext container and now the Avalon container.  Of these 4 I think that
the BeanContext container and the Avalon framework container appear to have the
most to offer us.

One theme that came across very clearly in the Avalon framework documentation
was the need for well-thought-out interfaces between the components in the
container and between the components and the container itself.   I could see
how the Avalon interfaces were evolved to meet the needs of a server side
component framework and then I started wondering if the interfaces for an
embedded systems container would be similar or different than these interfaces?

So, I decided to do some embedded system container interface hunting by putting
together a visual mockup of what I thought a couple of Embedlet container based
applications might look like and then search these applications for interfaces.

This is what I came up with:

http://embedlets.sourceforge.net/devdocs/diagrams/embedlet_pictures1.png


The interfaces immediately wanted to sort themselves into digital-oriented
interfaces like:

BitProducer and BitConsumer


and analog signal oriented interfaces like:

SignalStreamProducer and SignalStreamConsumer


The Embedlets themselves seemed to want to divide themselves into standard
Embedlets that lived in the middle of the container and Device & Service proxy
Embedlets that encapsulated connections to devices and services outside of the
container.  These proxy Embedlets appeared to work best attached to the inside
walls of the container to indicate that they had some kind of connection to the
outside world.

As I came up with generalized device proxy Embedlets to solve my programming
problems they started to look like what James describes as 'Abstract
Peripherals' and it occurred to me that perhaps if people did similar mockups
of the Embedlet container implementations they are interested in that more of
these 'Abstract Peripherals' would be discovered.

A final observation was that if an Embedlet container could be implemented
anywhere then why not allow it to be embedded inside of another Embedlet
container?  As an alternative to programming some of the Embedlets in Java
source code, it seemed that there should be no problem with programming the
internal logic of an Embedlet using another Embedlet container.


I only pulled out some of the 'low hanging fruit' interfaces from these mockups
because they were easy to see.  I wonder what some of the other interfaces are?


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Avalon [from JStamp List]

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

>Yes...that would be the case.

I actually don't have a problem with using Avalon as the framework if we
also except that for some implementations the embedded java device simply
won't have the capacity to run to the avalon framework classes no matter how
light they are.

This is actually another really good example of distributing complexity to
the server to keep the embedded end as lean as possible. Previously we used
the proxy interface as an example of capabilities the server would offer us
and this time it is the ability to use Avalon framework and STILL enable the
whole embeddlet infrastructure to work if we except the proviso that where
the embedlet runs can be either server or remote side.

Previously you stated that you simply would not be involved if all
implementations could not run the embeddlets on both a the server and remote
side. If we go with avalon it will be a real squeeze to guarantee the
embedlets can run on uVM.

It simply makes sense to be able to configure the complexity to run
whereever it can run in any one system which means I continue to stick to
the idea of being able to run the embeddlets server side and in fact use
avalon as a demonstration of the advantages of doing so.

JC


=======================================================
The following was a post on the JStamp list from Andrzej which I have
responded to on this list
=======================================================

JC comments:

> But does this mean that the embedded Java device
> now has to support the avalon base classes to execute the embedlet
> container?..hmmm

Yes...that would be the case.  But they are modular and lightweight enough
(at
least for the framework) that I don't see this as a big issue.  If we don't
adopt
some pre-existing framework (like Avalon) then we'll probably just end up
writing our own versions of the same classes, which will take longer, likely
repeat some mistakes, and not buy us much in class size.


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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of
James Caska
Sent: Wednesday, January 01, 2003 8:01 PM
To: emb...@li...
Subject: [Embedlets-developer] Hello!! <echo>Hello</echo>
<echo>Hello</echo> <echo>Hello</echo>


This is the sound of an empty LIST!!

Looking forward to the rest of the embedlets crew wander accoss to the new
list!


JC





-------------------------------------------------------
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

Re: [Embedlets-developer] Hello!

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

John,

Nice to have you aboard!  You know, at first I thought that the wide
range of ideas that everyone had about what an Embedlet container
should be used for was a bad sign.  It appears, however, that the
diversity might prove to be one of the idea's main strengths...

Evidently the paths traveled when discovering a new technology are
full of unexpected twists!

Ted

--- John Lowe <jd...@fr...> wrote:
> Hi all,
> 
> I've been monitoring the Embedlet thread in the JStamp Yahoo group,
> and 
> wanted to follow along, possibly contribute. I have my own "pet"
> projects 
> that would benefit from an Embetlet- I think cataloging these
> "pets" is a 
> very good idea- get some use cases to set a context that everyone
> can 
> relate to. Anyway, I just wanted to add myself to the list and will
> 
> contribute more after the JStamp migration.
> 
> -John (aka Squire0412@yahoo)
> 
> 
> 
> -------------------------------------------------------
> 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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Hello!

[John L. <jd...@fr...>]

Hi all,

I've been monitoring the Embedlet thread in the JStamp Yahoo group, and 
wanted to follow along, possibly contribute. I have my own "pet" projects 
that would benefit from an Embetlet- I think cataloging these "pets" is a 
very good idea- get some use cases to set a context that everyone can 
relate to. Anyway, I just wanted to add myself to the list and will 
contribute more after the JStamp migration.

-John (aka Squire0412@yahoo)

Re: [Embedlets-developer] Hello!! <echo>Hello</echo> <echo>Hello</echo> <echo>Hello</echo>

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

James!

I saw your subject line in my email inbox and I wondered what I did
wrong with the list configuration!  It took me a good 20 seconds to
figure out what was going on!

So much for me having a brilliant start to the new year :-)


Ted




--- James Caska <ca...@vi...> wrote:
> This is the sound of an empty LIST!!
> 
> Looking forward to the rest of the embedlets crew wander accoss to
> the new
> list!
> 
> 
> JC
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Hello!! <echo>Hello</echo> <echo>Hello</echo> <echo>Hello</echo>

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

This is the sound of an empty LIST!!

Looking forward to the rest of the embedlets crew wander accoss to the new
list!


JC

[Embedlets-developer] Welcome! And a short project background

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

Welcome to the embedlets-developer list!  Work on the
Embedlets idea actually began about a month and a half
ago and so a short background about this project is
probably in order.  The Embedlet container
specification and Outpost reference implementation
ideas got their start roughly on 11/15/2002 on the
JStamp users list
(http://groups.yahoo.com/group/jstamp).  

The idea grew from a discussion about what some of the
best practice patterns might be for dealing with the
large and growing number of embedded devices that are
going to be attached to the Internet and backend
enterprise systems in the near future.  

We were very fortunate to have a number of Java
developers on the list who had experience and
expertise in both embedded and enterprise systems
(which is a very rare combination) and so in the month
and a half between 11/15/2002 and 12/31/2002 we were
able to make significant headway towards conceiving of
an embedded Java based technology to help with this
problem.

The list traffic devoted to this topic became so large
that we finally decided to start an official open
source development project devoted to it and this is
the reason that the Embedlets sourceforge site was
launched.  The JStamp list archives from 11/15/2002
until 12/31/2002 hold a great deal of development
materials related to the Embedlets project and
hopefully we will eventually be able to copy these
founding materials onto this site for easy reference.

Ted Kosan
tk...@ya...


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Test!

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

Yes, this is one of those strange list test messages
that one periodically encounters.  Now I know what it
feels like to be on the sending end of one of these!

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com