forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott hutinger <s-hutin...@wiu.edu>
Subject Re: plugins possible output?
Date Thu, 18 Nov 2004 16:25:50 GMT
Sean Wheller wrote:

>On Thursday 18 November 2004 17:33, Ross Gardler wrote:
>  
>
>>> What about runtime
>>>input/output?  Would that require another architecture, or would that
>>>fit within a plugin?  Possibly in some strange not intended way.  I
>>>think if one looks at publishing, it could really mean runtime
>>>input/output.  Or is that a moot point?
>>>Possibly add an i/o plugin in the future?
>>>      
>>>
>>I'm not 100% certain what you mean here. Do you mean dynamic input of
>>data, from something like a piece of machinery with sensors? If you do
>>then you have me excited, I have exactly that use case. I think it can
>>be done as plugins, but I'm not due to start on that particular work
>>until January.
>>    
>>
>
>Cocoon does have a J2EE connector, you can also use Web Services and then if 
>you have an XML DB the XML:DB collector. So long as the device defines an 
>interface that is supported by cocoon, then it should not be a problem.
>  
>
Yes, exactly what I had in mind.  Runtime i/o, although I wasn't 
thinking realtime, the input really doesn't matter.  I was thinking more 
along the lines of taking data from a handheld and doing i/o from both 
the device and the host machine, or one way either way.  Derby comes to 
mind, although I am a bit uncertain about the need for an extra level 
(XML DB), but I don't have any real 'stats' based on that level of 
indirection to base any conclusion.

With that in mind, I think forrest could be a platform to base all sorts 
of needs.   I was looking for a delivery platform, but think I found a 
lot more than I thought I would find :-)  I'll keep the j2ee connector 
in mind when I read the docs...

thanks,
scott

Mime
View raw message