embedlets-developer Mailing List for Outpost Embedlet Container (Page 38)
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: Ted K. <tk...@ya...> - 2003-01-29 07:49:45
|
Christopher, > Just a queation on OfficeSuite XML format - I do not see this in the docs > that have been posted, they are all binary format. Am I missing something? By 'OfficeSuite' do you mean 'OpenOffice' or some other office suite? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-01-29 07:44:38
|
Christopher, >Until I downloaded the Office Suite I felt a > little excluded and had to scramble to be able to read the existing docs. Ok, it took a little bit of effort to download OpenOffice and install it but now that you did, do you have any comments on the pluses or minuses of having intimate access (and instant editing capabilities) to all of the documentation (including drawings) that was present there? From my perspective, all of the information is in one place under the control of one tool and can be easily edited and maintained. Actually, the OpenOffice files that are in the CVS are just my personal scratchpad documents that I decided to place under version control in my little corner of the repository. I bet you are the first person that has looked at them besides myself! (BTW, anyone that wants to place a personal scratchpad folder in the CVS feel free!) As for the core documents I agree, our next step is definitely to start developing them... as soon as we can agree on a file format. > My personal style is to use a drawing tool (Word, Visio or > OfficeSuite/StarOffice) to create the graphics then drop them into an WYSWYG > html editor Well, what do we do when it is discovered that one of the drawings has an error in it or that it needs to be updated? My opinion is that the source drawing document that the JPEG snapshot was taken from needs to be under version control and in a format that is easily editable using open tools. And really, I do not care what tool we select as long as it has the power of an office suite, uses open XML file formats and is open source. It just so happens that OpenOffice meets these criteria but I would gladly look at other alternatives that meet them too. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 07:38:21
|
If the protocol is TCP/IP and XML based there is no reason that VB, VBA and .NET could not be supported easily without impacting the specification. This could be in the form of a SOAP envelop that wraps the Embedlet XML packet or direct Embedlet XML packet generation. VB (6.0) and VBA are still the most widely used tools for enterprise process automation and should not be ignored if the technology expects to garner widespread acceptance. -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Tuesday, January 28, 2003 11:06 PM To: emb...@li... Subject: [Embedlets-developer] Re: PLC help James, Another way to market the Embedlet Container idea might be to say that it is a Virtual Embedded System that can easily be interfaced to a wide number of existing systems and can be placed into a wide range of platforms (from very small PICs up through larger embedded controllers, PCs and even servers). I find it very interesting that you are discussing the project with members of the PIC list and it is probably very telling that this specific person wanted to know if the technology was going to be compatible with VB.net right from the start. And you know, he had an interesting idea. I guess as long as the PC he was running on had a current version of the JRE (or maybe JDK) on it, something like the JavaBeans-to-ActiveX bridge (http://java.sun.com/products/javabeans/software/bridge/) might allow him work with Embedlets? I also noticed you used the original wide-fan-out document that was created early on. I suppose that as soon as our strategy firms up over the next couple of weeks that I should start building the Embedlets website up a bit so we can direct people there if they want to learn more about what we are doing. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: James C. <ca...@vi...> - 2003-01-29 07:31:54
|
Ted, > I find it very interesting that you are discussing the project with members of the PIC list Must admit though.. I can feel alot of 'blank faces' on the other sides of the screen. Its going to take a while to get the message accross one feels. > like the JavaBeans-to-ActiveX bridge > > (http://java.sun.com/products/javabeans/software/bridge/) > > might allow him work with Embedlets? Yes, I am keen to just keep in mind the dark-side-of-the-force and make sure if it is easy to do so, ensure Embedlets work in that framework also or at least have some bridging or Adaptlet technique to make it work. >wide-fan-out document that was created Distributed wireless companies have been showing a bit of interest in muvium so I am experimenting with ways to talk about this to get the message accross. The 'pitch' if you like. I think the wide-fan-out document is the best 'visual summary' we have so far of the Systems objectives, ie without really even getting into the nitty gritty of the containers etc. Its like the 'Big Picture' for that type of app. I certainly like the idea of developing the Embedlets website with materials like this to help commercial interests understand the opportunities that come from the Embedlets specification. James > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Wednesday, January 29, 2003 6:06 PM > To: emb...@li... > Subject: [Embedlets-developer] Re: PLC help > > > James, > > Another way to market the Embedlet Container idea might be to say > that it is a > Virtual Embedded System that can easily be interfaced to a wide number of > existing systems and can be placed into a wide range of platforms > (from very > small PICs up through larger embedded controllers, PCs and even servers). > > I find it very interesting that you are discussing the project > with members of > the PIC list and it is probably very telling that this specific > person wanted > to know if the technology was going to be compatible with VB.net > right from the > start. > > And you know, he had an interesting idea. I guess as long as the > PC he was > running on had a current version of the JRE (or maybe JDK) on it, > something > like the JavaBeans-to-ActiveX bridge > > (http://java.sun.com/products/javabeans/software/bridge/) > > might allow him work with Embedlets? > > > I also noticed you used the original wide-fan-out document that > was created > early on. I suppose that as soon as our strategy firms up over > the next couple > of weeks that I should start building the Embedlets website up a > bit so we can > direct people there if they want to learn more about what we are doing. > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 07:30:44
|
Just a queation on OfficeSuite XML format - I do not see this in the docs that have been posted, they are all binary format. Am I missing something? -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Jac Kersing Sent: Tuesday, January 28, 2003 11:11 PM To: emb...@li... Subject: Re: [Embedlets-developer] Re: OpenOffice On Tue, 28 Jan 2003, Ted Kosan wrote: > What do other people on the list think? Are we going to encode the core > specification documents inside of a modern, open, XML based office suite > format or are we going to chisel it into clay tablets? ;-) How about using DocBook? Still XML but everyone would be able to use their own 'pet' editor. And using the right tools it can be published in at least HTML, PDF, RTF. Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 07:30:41
|
This is my first open source development, but I have a few years of sitting in the cross fire on several enterprise software projects. The trick is to keep an open and energetic environment that allows people to express their creativity and opinions without resorting to weaponry. The one thing that is always tough to keep in perspective when two competing ideas are contentiously debated is that sometimes no decision is worse than the 'wrong' decision. -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Tuesday, January 28, 2003 9:48 PM To: emb...@li... Subject: [Embedlets-developer] Re: Catching up on the postings. Chris, Nice to have you on board! > Sorry for the dissertation, I got carried away on my first posting. Ha! In this list, if your post had been any shorter than it was we would have considered you to be a weakling. ;-) Actually, your suggestions have come at a good time because I think we are just now turning our attention to how we are going to organize and manage the project. Up until this point I think we have been mostly getting to know each other a little better and of course beating the snot out of each other a bit too! We have been pounding on the Embedlets idea since about mid November 2002 and one thing I think we have definitely discovered is that it is a very challenging area to attain consensus in due to its diverse nature. The good news is that most of the ideas and issues that people care about have already been submitted to the list and over the next few days (and probably through the weekend) I plan on extracting this information and placing it into a shared document so that we can start to organize and prioritize it. It sounds like you have some open source experience under your belt? If so, can you tell us a bit more about it? Also, your code base sounds interesting. Can you give us some more details about it too? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 07:10:22
|
My opinion is that the end product should definitely conform to the one of two accepted standards: pdf or html. This has the advantage that the effort is exposed openly and early. Until I downloaded the Office Suite I felt a little excluded and had to scramble to be able to read the existing docs. The source tools should be irrelevant and not consume a lot of valuable discussion time. I loaded the Office Suite because I happen to like it and if there is a choice that has to be made Office Suite is as good as any. My personal style is to use a drawing tool (Word, Visio or OfficeSuite/StarOffice) to create the graphics then drop them into an WYSWYG html editor (FrontPage, OfficeSuite, Dreamworks) as jpegs. That way the final documentation output is produced as you go and does not have to be reformatted for formal presentation. -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Tuesday, January 28, 2003 10:28 PM To: emb...@li... Subject: [Embedlets-developer] Re: OpenOffice Brill, > The problem is not that its an XML file format... the problem is that in > order to use it, I have to install and use a not-insignificant application > that I have no interest in using (though I'm sure its a great app). Well, you know, it pretty much installs itself and if one is mostly only going to be typing text and leaving the formatting chores up to others then the learning curve is very short. You should be up and running within 20 minutes max. > So, that's why I suggest HTML. If formatting is essential, doesn't > OpenOffice have a WYSIWYG editor like FrontPage or something? > The current version of FrontPage is actually pretty good... not a lot of > garbage... surely OpenOffice has something like that? Sure, OpenOffice has a WYSIWYG editor but any WYSIWYG editors are going to fight each other to have the document's tag selection and formatting placed in its own pet style. I have tried this and it does not work well at all. Here is my perspective. I have downloaded and read through a number of specifications like the Servlet spec, the JavaBeans spec, the EJB spec and most recently the new Sun ACE spec. Most specifications contain a ton of typing, formatting, sectioning and sub-sectioning. A number of them also contain a significant number of diagrams. Since I bet I have more free time than anyone else on the list (you guys have no idea how much free time a university faculty member has!) the responsibility for typing in, formatting, reformatting and maintaining the specifications we generate will probably fall on my shoulders. As I analyze this I am not at all looking forward to the prospect of having to do this work using raw text or even HTML. Beyond this, if our core working documents are in raw text or HTML I also do not want to have to go through the work of copying them into an office suite for formatting every time a new version of the specification is released. I am kind of stuck on this issue right now because it looks like we are within a week or so of actually starting work on developing the specification documents and I would personally rather resolve this issue sooner rather than later. What do other people on the list think? Are we going to encode the core specification documents inside of a modern, open, XML based office suite format or are we going to chisel it into clay tablets? ;-) Again, if everone mostly leaves the formatting chores up to me, entering and editing text using OpenOffice is quite easy. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-01-29 07:09:26
|
Jac, > How about using DocBook? Still XML but everyone would be able to use their > own 'pet' editor. And using the right tools it can be published in at > least HTML, PDF, RTF. I think DocBook might be very promising. Do you have any favorite editors that I might look at first to get me started? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-01-29 07:06:07
|
James, Another way to market the Embedlet Container idea might be to say that it is a Virtual Embedded System that can easily be interfaced to a wide number of existing systems and can be placed into a wide range of platforms (from very small PICs up through larger embedded controllers, PCs and even servers). I find it very interesting that you are discussing the project with members of the PIC list and it is probably very telling that this specific person wanted to know if the technology was going to be compatible with VB.net right from the start. And you know, he had an interesting idea. I guess as long as the PC he was running on had a current version of the JRE (or maybe JDK) on it, something like the JavaBeans-to-ActiveX bridge (http://java.sun.com/products/javabeans/software/bridge/) might allow him work with Embedlets? I also noticed you used the original wide-fan-out document that was created early on. I suppose that as soon as our strategy firms up over the next couple of weeks that I should start building the Embedlets website up a bit so we can direct people there if they want to learn more about what we are doing. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Jac K. <j.k...@th...> - 2003-01-29 07:02:52
|
On Tue, 28 Jan 2003, Ted Kosan wrote: > What do other people on the list think? Are we going to encode the core > specification documents inside of a modern, open, XML based office suite > format or are we going to chisel it into clay tablets? ;-) How about using DocBook? Still XML but everyone would be able to use their own 'pet' editor. And using the right tools it can be published in at least HTML, PDF, RTF. Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Ted K. <tk...@ya...> - 2003-01-29 06:28:17
|
Brill, > The problem is not that its an XML file format... the problem is that in > order to use it, I have to install and use a not-insignificant application > that I have no interest in using (though I'm sure its a great app). Well, you know, it pretty much installs itself and if one is mostly only going to be typing text and leaving the formatting chores up to others then the learning curve is very short. You should be up and running within 20 minutes max. > So, that's why I suggest HTML. If formatting is essential, doesn't > OpenOffice have a WYSIWYG editor like FrontPage or something? > The current version of FrontPage is actually pretty good... not a lot of > garbage... surely OpenOffice has something like that? Sure, OpenOffice has a WYSIWYG editor but any WYSIWYG editors are going to fight each other to have the document's tag selection and formatting placed in its own pet style. I have tried this and it does not work well at all. Here is my perspective. I have downloaded and read through a number of specifications like the Servlet spec, the JavaBeans spec, the EJB spec and most recently the new Sun ACE spec. Most specifications contain a ton of typing, formatting, sectioning and sub-sectioning. A number of them also contain a significant number of diagrams. Since I bet I have more free time than anyone else on the list (you guys have no idea how much free time a university faculty member has!) the responsibility for typing in, formatting, reformatting and maintaining the specifications we generate will probably fall on my shoulders. As I analyze this I am not at all looking forward to the prospect of having to do this work using raw text or even HTML. Beyond this, if our core working documents are in raw text or HTML I also do not want to have to go through the work of copying them into an office suite for formatting every time a new version of the specification is released. I am kind of stuck on this issue right now because it looks like we are within a week or so of actually starting work on developing the specification documents and I would personally rather resolve this issue sooner rather than later. What do other people on the list think? Are we going to encode the core specification documents inside of a modern, open, XML based office suite format or are we going to chisel it into clay tablets? ;-) Again, if everone mostly leaves the formatting chores up to me, entering and editing text using OpenOffice is quite easy. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-01-29 06:04:58
|
> Finally (if you have not lost interest), I would like to offer to > contribute > a large body of work on a implementation that embodies a number of the > concepts envisioned in Embedlets. Christopher.. Wow! great first post. Is this a body of work that has already been implemented 'along the lines of Embedlets' or is this work you are volunteering to do. I think what Ted will say is that you have taken the words right out of his mouth.. as a group we have only just right now 'converged' enough to present the type of implementation outline you have jump-started us with. Great work. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Wednesday, January 29, 2003 1:17 PM > To: emb...@li... > Subject: [Embedlets-developer] Catching up on the postings. > > > In reviewing the postings of the last couple of weeks it appears that a > solid development path has yet to be laid and the project members have not > yet achieved consensus on the priorities and division of effort. This is > natural for a startup project such as this. Some of the issues are sticky > and contentious others are generally agreed on. > > May I suggest that: > > 1. A list of the issues/tasks be created and prioritized > 2. Each task gets portioned out to one or two individuals based > on skill and > desire > 3. The results of the efforts posted to cvs as ready > 4. A discussion thread for each task is created open to the group as a > whole. > 5. Contentious issues can be tabled for later resolution in favor of those > that can produce real results in short order. > > A two level list might look like: > > 1. Container specifications > add/remove/locate methods > embedlet instantiation and population > life cycle > RPC methods (getEmbedletPropeties, setEmbedletProperties, > start, stop etc) > 2. Embedlet specification > container facing interface > persistence interface > life cycle > error management > 3. Event API > Listener > Source > Methods > RT thread issues > 4. XML persistence and serialization > Properties interface (getProperty(), setProperty()) > XML schema (not necessarily enforced) > parser selection and minimal requirements (SAX, DOM, > unidirectional pull?) > 5. Communication protocol > Request/response > retry recovery > socket pooling and management > 6. Storage (local persistence) > CLDC based? > Stream or database? > 7. GUI specifications > Java bean subclass > Design paradigm > 8. Web services specification > http/XML envelope > SOAP transport > JSP/J2EE/ASP/.NET examples > 9. Mobile and wireless specifications > CLDC/MIDP > Socket/proxy requirements > parser > configuration > > Obviously a list like this needs to be distributed amongst the developers > involved, although we will all have strong opinions in some or all of the > areas our efforts should be directed at generating a solid, simple > specification and reference implementation that can be understood and > accepted. > > Finally (if you have not lost interest), I would like to offer to > contribute > a large body of work on a implementation that embodies a number of the > concepts envisioned in Embedlets. I am offering to present the API and > implementation for critique, inclusion in or conversion to the Embedlets > specification and/or as the basis for a reference implementation. > I see this > code base as a good head start that proves the concepts of Embedlets but > requires conformity to a standard that will endure and be accepted by the > embedded community at large. > > Sorry for the dissertation, I got carried away on my first posting. > > Christopher Smith > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: James C. <ca...@vi...> - 2003-01-29 05:53:52
|
>But seriously, why do you think I've been stressing the >availability of a "connector embedlet" Thats all I really mean't just to be sure that it is 'visible' in the right place from the beginning. >As for creating C# implementations <snip> I wasn't suggesting we do this in C# only that .NET is going to linger and cross pollinate with Java so we should be ready for it. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Andrzej Jan Taramina > Sent: Wednesday, January 29, 2003 9:42 AM > To: emb...@li... > Subject: [Embedlets-developer] Re: .NET, "dead" XML configs, > Schemas/DTDs, and catchups.... > > > James is concerned: > > > The point is that we certainly should ensure our embedlet > specification is > > able to work with .NET at some point along the chain and we > should design > > for it if possible or is this simply an outrageous thing to say > to a bunch > > of java die hards! > > .NET? What's that? Hasn't M$ dropped the .NET moniker? Lord knows what > they will call it next...hey, that might be it: from: OLE to COM > to COM+ to > DCOM to .NET to .NEXT? ;-) > > But seriously, why do you think I've been stressing the availability of a > "connector embedlet" that will use XML/SOAP to communicate to back end > systems using Web Services? That approach means we'll be able to > integrate > embedlets running inside the Outpost container to J2EE, .NET and > any other > Web Services-enabled back end system....targetting the maximum amount of > integration capability. > > As for creating C# implementations, I see little value to that > in the short term > (aJile/Systronix are not likely to support C# on their platforms > too soon). Let's > get a Java version running first. Then a Java <--> C# bytecode > translator > might be an easy way to accomplish this, if there is a demand. > Or just re- > implement Outpost as Outpost# (if someone cares to do such). > > Brill then comments: > > > IMO, this is the key to this system... setting it up "dead" > would be fairly > > easy to do and doesn't bring any unique aspect.... which would > put up my "So > > What?" radar. > > Almost every other container system out there does it this > way.....XML config > files rather than serialized instances. It's considered a "best > practice" for a > reason. Just because it's not unique and "gee whiz" does not mean we > shouldn't use it. The goal of Outpost is very practical in > nature.....so "gee > whiz" stuff should be left behind, unless it clearly advances the > goals. When > building a Container/Component system, there are many things that have to > be specified that really don't belong inside the component > instance object (and > hence it's serialized form). > > Jac doesn't like schemas: > > > Having to know XML is not too much of a problem. Most people > are able to > > learn XML. The problem with XML is the DTD, how many XML > documents are you > > working on and how many DTD do you need to know to be able to create > > correct XML documents? > > You don't need a schema to use XML. Validation for configuration > files is not > all that valuable, and even if it will add some limited value, > the validation and > schemas can be added after the fact quite easily, inferring these > from the XML > tags themselves. The config file structure should be quite > intuitive....probably > modeled on servlet descriptors to some degree, just for > familiarity reasons. > > > Having even a simple application available to create a valid > configuration > > is very valuable IMHO. A wiring tool would be great! > > Yup....that would be a real nice to have for sure! > > Ted plays catchup: > > > t took me 5 solid hours to read through and absorb all the > traffic that you > > guys generated (sheesh, was it a full moon or something!?) and > there were a > > significant number of absolutely critical ideas that were submitted. > > Nope...been meaning to post some stuff and finally got around to > it. Will be > posting some Container design ideas very shortly too....so we can > start settling > that down a bit to the point where I can start slinging some initial code. > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Ted K. <tk...@ya...> - 2003-01-29 05:47:30
|
Chris, Nice to have you on board! > Sorry for the dissertation, I got carried away on my first posting. Ha! In this list, if your post had been any shorter than it was we would have considered you to be a weakling. ;-) Actually, your suggestions have come at a good time because I think we are just now turning our attention to how we are going to organize and manage the project. Up until this point I think we have been mostly getting to know each other a little better and of course beating the snot out of each other a bit too! We have been pounding on the Embedlets idea since about mid November 2002 and one thing I think we have definitely discovered is that it is a very challenging area to attain consensus in due to its diverse nature. The good news is that most of the ideas and issues that people care about have already been submitted to the list and over the next few days (and probably through the weekend) I plan on extracting this information and placing it into a shared document so that we can start to organize and prioritize it. It sounds like you have some open source experience under your belt? If so, can you tell us a bit more about it? Also, your code base sounds interesting. Can you give us some more details about it too? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-01-29 05:45:30
|
The problem is not that its an XML file format... the problem is that in order to use it, I have to install and use a not-insignificant application that I have no interest in using (though I'm sure its a great app). So, that's why I suggest HTML. If formatting is essential, doesn't OpenOffice have a WYSIWYG editor like FrontPage or something? The current version of FrontPage is actually pretty good... not a lot of garbage... surely OpenOffice has something like that? - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Wednesday, January 29, 2003 12:26 AM Subject: [Embedlets-developer] Re: OpenOffice > Brill, > > > you have to mark a file as binary instead of text when you check it into CVS > > (do it all the time with no problems)... > > Well yes, one can check binary files into CVS but they are just stored there > and are not under version control. If two people change part of a binary file > and then submit the changes, CVS can not tell whether there was a collision or > not. > > > > > Ok, HTML then ;) I bet OpenOffice can edit HTML in a WYSIWYG, which word can > > also do. Not only that, but it means the docs can be dropped on the server > > for easy display. > > What about spread sheets and diagrams? Beyond this, HTML is a great > presentation technology but I think that XML is a much more flexible technology > to place editable content into. > > Do you know of any better XML file formats than the OpenOffice XML file format > that is designed for office-suite class document storage? > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-01-29 05:39:34
|
I've been chatting with Andrzej in private e-mail (I guess it should have gone to the list) about the XML thing... He basically filled me in on some of the stuff I missed over the holiday "break" we had, and I'm now up to speed. Anyway, no more argument from me about the XML, as when built right it won't matter. - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Christopher Smith" <cs...@oo...> To: <emb...@li...> Sent: Tuesday, January 28, 2003 9:17 PM Subject: [Embedlets-developer] Catching up on the postings. > In reviewing the postings of the last couple of weeks it appears that a > solid development path has yet to be laid and the project members have not > yet achieved consensus on the priorities and division of effort. This is > natural for a startup project such as this. Some of the issues are sticky > and contentious others are generally agreed on. > > May I suggest that: > > 1. A list of the issues/tasks be created and prioritized > 2. Each task gets portioned out to one or two individuals based on skill and > desire > 3. The results of the efforts posted to cvs as ready > 4. A discussion thread for each task is created open to the group as a > whole. > 5. Contentious issues can be tabled for later resolution in favor of those > that can produce real results in short order. > > A two level list might look like: > > 1. Container specifications > add/remove/locate methods > embedlet instantiation and population > life cycle > RPC methods (getEmbedletPropeties, setEmbedletProperties, start, stop etc) > 2. Embedlet specification > container facing interface > persistence interface > life cycle > error management > 3. Event API > Listener > Source > Methods > RT thread issues > 4. XML persistence and serialization > Properties interface (getProperty(), setProperty()) > XML schema (not necessarily enforced) > parser selection and minimal requirements (SAX, DOM, unidirectional pull?) > 5. Communication protocol > Request/response > retry recovery > socket pooling and management > 6. Storage (local persistence) > CLDC based? > Stream or database? > 7. GUI specifications > Java bean subclass > Design paradigm > 8. Web services specification > http/XML envelope > SOAP transport > JSP/J2EE/ASP/.NET examples > 9. Mobile and wireless specifications > CLDC/MIDP > Socket/proxy requirements > parser > configuration > > Obviously a list like this needs to be distributed amongst the developers > involved, although we will all have strong opinions in some or all of the > areas our efforts should be directed at generating a solid, simple > specification and reference implementation that can be understood and > accepted. > > Finally (if you have not lost interest), I would like to offer to contribute > a large body of work on a implementation that embodies a number of the > concepts envisioned in Embedlets. I am offering to present the API and > implementation for critique, inclusion in or conversion to the Embedlets > specification and/or as the basis for a reference implementation. I see this > code base as a good head start that proves the concepts of Embedlets but > requires conformity to a standard that will endure and be accepted by the > embedded community at large. > > Sorry for the dissertation, I got carried away on my first posting. > > Christopher Smith > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-01-29 05:26:21
|
Brill, > you have to mark a file as binary instead of text when you check it into CVS > (do it all the time with no problems)... Well yes, one can check binary files into CVS but they are just stored there and are not under version control. If two people change part of a binary file and then submit the changes, CVS can not tell whether there was a collision or not. > Ok, HTML then ;) I bet OpenOffice can edit HTML in a WYSIWYG, which word can > also do. Not only that, but it means the docs can be dropped on the server > for easy display. What about spread sheets and diagrams? Beyond this, HTML is a great presentation technology but I think that XML is a much more flexible technology to place editable content into. Do you know of any better XML file formats than the OpenOffice XML file format that is designed for office-suite class document storage? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-01-29 04:27:49
|
Bruce said: >I recently - at Ted's urging - loaded OpenOffice and just upgraded to 1.0.2 In all fairness I also indicated that it definitely had some warts but that most of these had work arounds. One very positive thing that it has going for it is that it has a very strong open source development community around it who are actively fixing bugs. From looking through their lists it also seems that their response to help requests is very good. For the most part it is usable now and it is continuously getting better. Also, I have been using version 1.01 almost every day (often for 8+ hours a day) for over a year now (on both Linux and Windows98) and I have not had it crash even once. Perhaps they put some bugs into version 1.02? And experiencing 3D done the German way is quite a treat! ;-) Anyway, if there were a better open source office suite available that used open XML file formats I would certainly consider switching. As for the book, I still think that using a CVS is the way to go if the book is going to be collabratively developed. If one can not use sourceforge's CVS then I guess that you can set one up some place else. It only takes about 15 minutes to get CVS up and running on Linux. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 02:16:41
|
In reviewing the postings of the last couple of weeks it appears that a solid development path has yet to be laid and the project members have not yet achieved consensus on the priorities and division of effort. This is natural for a startup project such as this. Some of the issues are sticky and contentious others are generally agreed on. May I suggest that: 1. A list of the issues/tasks be created and prioritized 2. Each task gets portioned out to one or two individuals based on skill and desire 3. The results of the efforts posted to cvs as ready 4. A discussion thread for each task is created open to the group as a whole. 5. Contentious issues can be tabled for later resolution in favor of those that can produce real results in short order. A two level list might look like: 1. Container specifications add/remove/locate methods embedlet instantiation and population life cycle RPC methods (getEmbedletPropeties, setEmbedletProperties, start, stop etc) 2. Embedlet specification container facing interface persistence interface life cycle error management 3. Event API Listener Source Methods RT thread issues 4. XML persistence and serialization Properties interface (getProperty(), setProperty()) XML schema (not necessarily enforced) parser selection and minimal requirements (SAX, DOM, unidirectional pull?) 5. Communication protocol Request/response retry recovery socket pooling and management 6. Storage (local persistence) CLDC based? Stream or database? 7. GUI specifications Java bean subclass Design paradigm 8. Web services specification http/XML envelope SOAP transport JSP/J2EE/ASP/.NET examples 9. Mobile and wireless specifications CLDC/MIDP Socket/proxy requirements parser configuration Obviously a list like this needs to be distributed amongst the developers involved, although we will all have strong opinions in some or all of the areas our efforts should be directed at generating a solid, simple specification and reference implementation that can be understood and accepted. Finally (if you have not lost interest), I would like to offer to contribute a large body of work on a implementation that embodies a number of the concepts envisioned in Embedlets. I am offering to present the API and implementation for critique, inclusion in or conversion to the Embedlets specification and/or as the basis for a reference implementation. I see this code base as a good head start that proves the concepts of Embedlets but requires conformity to a standard that will endure and be accepted by the embedded community at large. Sorry for the dissertation, I got carried away on my first posting. Christopher Smith |
|
From: Brill P. <bri...@ro...> - 2003-01-29 00:18:50
|
Heck, I used to have a "light" text edit project going on sourceforge (lexi.sourceforge.net) I have no idea what state its in... I passed off the project to another fellow. > Also I checked into SourceForge about storing documents there. One issue is > that as I read it, (reading legalese quickly makes my brain hurt, so I > don't do it often) once you store something there you can't later make it > "un-open source". So you can't (in my case) publish a draft of a book and > then at the time of publication, take those files away and only publish an > outline and excerpts, and 'transfer' ownership of the draft to the > publisher. So for me that's a show stopper. But the embedlet project should > have no such concerns. Just though you might want to know. Yah, a sticky issue for sure. Under any of the licences, you still hold the licence... so at any time you could take the resources for the project, and start a new version that wasn't open source.... you just can't remove something from the community once its been distributed and made available... The best practice (IMO) in a case like yours, is to only release the parts of the project you *want* people to have access to... or if its going commercial, branch your project into two related streams, one open, the other not so open. - Brill |
|
From: Andrzej J. T. <an...@ch...> - 2003-01-28 22:43:04
|
James is concerned: > The point is that we certainly should ensure our embedlet specification is > able to work with .NET at some point along the chain and we should design > for it if possible or is this simply an outrageous thing to say to a bunch > of java die hards! .NET? What's that? Hasn't M$ dropped the .NET moniker? Lord knows what they will call it next...hey, that might be it: from: OLE to COM to COM+ to DCOM to .NET to .NEXT? ;-) But seriously, why do you think I've been stressing the availability of a "connector embedlet" that will use XML/SOAP to communicate to back end systems using Web Services? That approach means we'll be able to integrate embedlets running inside the Outpost container to J2EE, .NET and any other Web Services-enabled back end system....targetting the maximum amount of integration capability. As for creating C# implementations, I see little value to that in the short term (aJile/Systronix are not likely to support C# on their platforms too soon). Let's get a Java version running first. Then a Java <--> C# bytecode translator might be an easy way to accomplish this, if there is a demand. Or just re- implement Outpost as Outpost# (if someone cares to do such). Brill then comments: > IMO, this is the key to this system... setting it up "dead" would be fairly > easy to do and doesn't bring any unique aspect.... which would put up my "So > What?" radar. Almost every other container system out there does it this way.....XML config files rather than serialized instances. It's considered a "best practice" for a reason. Just because it's not unique and "gee whiz" does not mean we shouldn't use it. The goal of Outpost is very practical in nature.....so "gee whiz" stuff should be left behind, unless it clearly advances the goals. When building a Container/Component system, there are many things that have to be specified that really don't belong inside the component instance object (and hence it's serialized form). Jac doesn't like schemas: > Having to know XML is not too much of a problem. Most people are able to > learn XML. The problem with XML is the DTD, how many XML documents are you > working on and how many DTD do you need to know to be able to create > correct XML documents? You don't need a schema to use XML. Validation for configuration files is not all that valuable, and even if it will add some limited value, the validation and schemas can be added after the fact quite easily, inferring these from the XML tags themselves. The config file structure should be quite intuitive....probably modeled on servlet descriptors to some degree, just for familiarity reasons. > Having even a simple application available to create a valid configuration > is very valuable IMHO. A wiring tool would be great! Yup....that would be a real nice to have for sure! Ted plays catchup: > t took me 5 solid hours to read through and absorb all the traffic that you > guys generated (sheesh, was it a full moon or something!?) and there were a > significant number of absolutely critical ideas that were submitted. Nope...been meaning to post some stuff and finally got around to it. Will be posting some Container design ideas very shortly too....so we can start settling that down a bit to the point where I can start slinging some initial code. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-01-28 22:17:27
|
> > What's wrong with plain text? > > No font control, no formatting, no universal end-of-line marker standard, no > automatic page numbers, no automatic headers and footers, no spell checking, no > spreadsheets, no editable diagrams. Ok, HTML then ;) I bet OpenOffice can edit HTML in a WYSIWYG, which word can also do. Not only that, but it means the docs can be dropped on the server for easy display. Or maybe us a Wiki... I can set up one there for light duty... > Every time we publish a new version of the spec I do not want to have to copy a > .txt version of it into a formatting tool. It seems much cleaner to me to just > put it under format control from day one with diagrams etc. constantly in > place. > > Aside from this, the main reason I proposed openoffice was that it uses XML > file formats that work well in a CVS (CVS does not like binary file formats). you have to mark a file as binary instead of text when you check it into CVS (do it all the time with no problems)... as for text, CVS automatically converts the EOL char for you, to the platform its being checked out to (if its checked in as text). - Brill |
|
From: Ted K. <tk...@ya...> - 2003-01-28 18:54:02
|
Brill, > What's wrong with plain text? No font control, no formatting, no universal end-of-line marker standard, no automatic page numbers, no automatic headers and footers, no spell checking, no spreadsheets, no editable diagrams. Every time we publish a new version of the spec I do not want to have to copy a .txt version of it into a formatting tool. It seems much cleaner to me to just put it under format control from day one with diagrams etc. constantly in place. Aside from this, the main reason I proposed openoffice was that it uses XML file formats that work well in a CVS (CVS does not like binary file formats). Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Jac K. <j.k...@th...> - 2003-01-28 17:57:30
|
On Tue, 28 Jan 2003, Ted Kosan wrote: > One way of looking at the wiring tool is that it just provides a way for > non-Java-programmers to graphically build the XML description of an > application without needing to know either Java or XML. Having to know XML is not too much of a problem. Most people are able to learn XML. The problem with XML is the DTD, how many XML documents are you working on and how many DTD do you need to know to be able to create correct XML documents? Having even a simple application available to create a valid configuration is very valuable IMHO. A wiring tool would be great! Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Brill P. <bri...@ro...> - 2003-01-28 17:37:03
|
<laugh> no, really.. was a mistake ;) every other list I use, replies to the list, so I forget to check sometimes ;) in fact, I didn't remember to check until this post ;) - Brill ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Tuesday, January 28, 2003 6:14 AM Subject: [Embedlets-developer] RE: Reply header -> switch was flicked > James said: > > >Not sure.. I think maybe ted has flicked a switch somewhere? > > Yes, I flicked the switch. I decided to chuck the conventional 'list reply > philosophy' after suffering through the amazing number of double posts that > were generated recently! > > What I am unsure of, however, is whether the bulk of these double posts were > accidental or not. I can't shake the suspicion that certain individuals on the > list may have resorted to gorilla tactics when persuasion did not prove to be > effective. ;-) > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
11 messages has been excluded from this view by a project administrator.