World: r3wp

I've started this group to discuss about the COM implementation on 
REBOL.

Te goal i would like to archive, is to have a dialect to "talk" to 
COM objects. is this to hard to do ? do we realy need this ? all 
cuestions are welcome 

To start i've wrapped a Library called DispHelper, make it a .dll 
and try to see i we can get any thing to work. you can find some 
alpha releases in this link http://www.geocities.com/benjaminmaggi/data/COMLib.zip, 
and some documentation here http://www.geocities.com/benjaminmaggi/doc/comlib.html

Is this wise to do? Trying to integrate with a messy framework, and 
where will you be in 2 years?

It might be necessary (I don't know your situation), but I for sure 
would keep a long distance to something like COM.

Yes, it is wise to do. He integrates with the IDispatch interface 
that all ActiveScripting languages on Windows use. If you want to 
control regular Windows applications this is the way to do it. When 
the .NET scripting interfaces are better established with Monad, 
then you might consider something different for .NET apps, but it 
will be a while before those take precedence. For the next couple 
years, traditional Windows applications are what you have to deal 
with.

It is wise, because it allows integration with what is out there 
right now (as opposed to two years time). Microsoft itself showed 
the importance of Word being able to integrate some years ago - helps 
people make a switch when they can still get to their legacy data.

:)

Just make sure that randoms can't send you scripting commands to 
pass along - Outlook has taught us that.

Instead of trying to integrate with Word, Excel, Outlook and the 
like, why not use the powder trying to convince people to use better 
applications and then integrate with them?

Then your work might not be vasted in two years time.

Hey, not all of us have that luxury. Some of us occasionally are 
forced by circumstances to use applications other than REBOL, if 
only because they have been written already. I would prefer to use 
REBOL to script these applications simply because the alternative 
would be any one of a couple dozen languages with ActiveScripting 
support (every major scripting language with a Windows build, including 
almost all of the open-source languages). Rewriting Excel in REBOL 
just isn't an option for me.

I do all of my command line scripting in REBOL, why not more?

so what is needed? A COM interface?

Benjamin's IDispatch interface is a good start. I've been thinking 
about ways to make it seem more REBOL-like from within REBOL.

I don't say, you should use a REBOL substitude for Excel. You have 
other options! OpenOffice has an excellent spreadsheet. I would guess, 
KOffice and other office packages has too. Why not switch to one 
of those and then integrate with them using REBOL?

In case you misunderstood me, I'm using alot of other technologies 
than REBOL, when e.g. sending emails, writing letters, producing 
PDFs, producing invoices, etc. I just try to choose good applications, 
that are easy to integrate with, and where I don't have to go into 
something like COM.

I am not the one who does the work in Excel. Accountants do. It is 
not my choice to make, and the choice can't be made at all for historical 
records. At the time they switched to Excel, yes I was the one who 
championed it, but there was no OpenOffice then, no KOffice, no REBOL, 
no Windows 95 even. I am just called in to do the things that are 
over their head and when I'm done, these things usually don't need 
to be done again. Two years from now a new set of problems wil need 
to be solved and they will likely still be using Excel.

I think that's a big ask .. to ask someone who already has Word installed 
to install OpenOffice just to use one's application.

I'm just asking! :-) Like Benjamin said above: "all questions are 
welcome"

I don't even have any office apps installed on MY system. Heck, I 
do most of the work on office apps on other computers, or virtual 
machines that I archive when I'm done.

I think that BrianH is right - we should not use excuses - suggesting 
someone other Office suite is really a childish. I work for company 
with 3K desktops - go figure ...

other languages do interface with COM, Rebol does not - go figure 
once again

Still, your point about COM being less-than-well-designed does have 
some merit :)

what Brian tries to communicate here is - he would like to use REBOL 
for such kind of work too ...

Hey, I even did some of my Statistics homework in REBOL :)

Pekr, when the company with 3K desktops need new computers and/or 
new versions of their software, can you figure, how much they would 
save, if they switched away from MSOffice? And then we might have 
a free world, where it would be alot easier for you guys to integrate 
with the applications being used.

Geomol... Retraining. Legacy data support for auditing purposes. 
People still using Office 97 or 2000 who don't need to upgrade at 
all.

Let's not distract from the message - a way to support COM in Rebol.

I can imagine - but we are not there yet. Imagine how MSOffice is 
integrated everywhere. We have e.g. SAP here. IT uses Excel as a 
grid in some transactions etc.

Let's keep politics in it's own channel.

It might be necessary to do the COM interface do to circumstances!? 
Maybe the company can't switch any time soon. I was just suggesting, 
that all the powder used to support COM might be better used.

Ma conclusion is - REBOL COM support would be still usefull, at least 
next few years, till open standards come ...

btw - what would be needed for REBOL to support so called CLI interface 
and becoming CLI language? COM support too?

Pekr, it would need a rewrite of REBOL to become a CLI language. 
On the other hand, it may not be necessary - the various .NET runtimes 
have excellent remoting support, very well documented. In the short 
term it would require SOAP support in REBOL - in the long run you 
could make a Remoting interface to LNS. Neither would be that hard.

what about plain tcp or via-file kinda of interface?

That would require a lot of rewriting of .NET code to add support 
for that kind of thing. It would be no less difficult than implementing 
SOAP for REBOL.

We should take a look at Monad to get the feeling for how the CLI 
will be intended to be scripted in the future.

For COM scripting we only have to be as good as your average ActiveScripting 
language. I would prefer to be better, but the bar isn't especially 
high.

.NET scripting is going to be another beast altogether: Monad is 
shaping up to be powerful indeed.

what is Monad?

Microsoft's new shell they are proposing for Longhorn and such, though 
it will work on any NT-kernel box with .NET 2.0 in theory. They are 
planning to enable shell scripting with piping of actual untranslated 
objects between commands. It is a lot more impressive than I make 
it sound here.

Let's stick with COM for now.

On that note, time to go off and think about this. Later!

btw: IIRC DocKimbel did some work on ActiveX interfacing some time 
ago. Sadly he is not active nor does he respond to email, so dunno 
if we could start from some already existing codebase ...

I am as usual worried about "run everywhere", because those apps 
may be missing.
But some random pros:
-Rebol as new arexx should be able to script apps.

-Peoples will have multiple computers (vmwared or others). It makes 
sense to script them all together. Have an office running somewhere 
to convert data etc.
-.net uses com internally afaik.

-firefox uses something similar. if IDispatch works with .net, it 
may be portable to access firefox-internals.

- .NET interfaces to COM and implements some of the framework by 
referencing existing native-code libraries, some of them through 
COM, but it doesn't use COM internally. It does include standard 
facilities for COM and .NET applications to interoperate. Other .NET-like 
runtimes don't use COM, and may not be able to.

- Good catch on Firefox and the Mozilla stuff, their XPCOM framework 
they build their components on works very similar to COM. It would 
require binding to different libraries through a slightly different 
interface but the REBOL-side dialect could be the same.

AFAIK their objects are internally com-objects. But had only a short 
read. But dont see why not, COM isnt that bad - concepts that is. 
Implementation and effort is another matter. But thats partially 
a lack of a good language. The component-pascal people had a lot 
of nice words for it - and a language/framework to fix its shortcomings 
:)) AFAIK .net is sugar around it - heavy sugar, vm, gc and such. 
But multi-language, windows arexx, versioning and such are already 
concepts of com.

Really, they're not. Any similarities are due to a need for interoperability 
and some influence on the designers of the new framework of the things 
that worked in COM. Internally, .NET objects are a lot more like 
those of Java than COM.

Im atending to CaFeLUG it's an open source 3 days long conference 
with various speakers and discutions, yesterday we have ms "maddog" 
hall, and today i get the chance to listen Roberto Di Cosmo, many 
french and italian people may know im, its has been a truly eye opening 
experience, i guess Argentina like many other countrys who use Privative 
Soft like MS windows (only because we can make the copy) its going 
to make a switch, the ability to copy windows will no longer exist, 
and the only real option is Open source because of the $$$ right 
now i think this will happen in no more than 5 years from now, i 
do not agree with the general idea o MS but i found COM to be a quite 
intresting thing its to sad to see how it's bloated by VB or C# but 
any whay its a nice thing they have. 

So in conclution its a good idea to have COM yes and no... yes because 
it will open a door for rebol and many programers (maybe) and no 
because the thecnology could become useless in 5 years (at least 
to me and people around me) 

I think it will take a few changes to make rebol COM compatible so 
it isn't a great deal programing it for a couple of years it may 
be a good thing to have.

But today there are some great things to do imagine REBOL's capabilityes 
integrated in the desktop a true desktop not the rebol one, REBOL 
stands in the middle between documents messaging information exchange 
etc... etc... just because it can integrate COM ....

BTW i found the rebol desktop verry userful in some tasks its geat 
i IOS is even better but the leack ability of interaction with aplications 
and elements out there make it a bit "closed" to my taste, dont get 
me wrong here, i just mean it for those people we use to call "useres" 
the weenies :-) we dont need that :-)

i've found a nasty bug on the rebol code, it avoided objects to be 
passed now looks much nicer and works... im working on some pritty 
examples WORD EXEL and more just the one's you can see on MSDN for 
VBS but workin in REBOL !!! wow comming soon ! you cant imagine all 
things you can do with this baby apart from crashing the system :-)