News and commentary from the cross-platform scripting community.
|
||
|
Mail Starting 3/12/98 | |
What I like most about FireWorks is that Macromedia chose PNG (Portable Network Graphics) for their preferred file format.
From: cmh@greendragon.com (Chris Hanson);
Sent at Sat, 14 Mar 1998 19:51:46 -0600;
FireWorksI went to the website with trepadation, expecting them to have developed Yet Another Proprietary Format and expect users to install Yet Another Plug-In to view it, and was very pleasantly surprised to see that they stood behind an open standard.
(Now they just need to open up Flash... :)
Like Richard, I definitely agree that Fireworks will be a bigger hit than Dreamweaver.
From: phil@gaijins.com (Philip Suh);
Sent at Sun, 15 Mar 1998 01:18:13 +0900;
FireworksWhile both are memory hogs--DreamWeaver takes 24meg of RAM, Fireworks 20meg--Dreamweaver takes 10 times the RAM as my current HTML editor (PageSpinner--and yes I know you can't really compare the feature set--or the price!). However Fireworks replaces both Photoshop and Illustrator and a litany of other plugins and small apps like clip2gif, GifBuilder, ImageMap, etc.
The Export function is to-die-for. It allows side-by-side comparison of your export options, which lets me compare the merits of a 5-bit GIF versus a 4-bit GIF--Ican see both the size of the file and the quality of the image.
It feels a little sluggish on my 240 mhz machine, but it's still in beta--hopefully it'll get better, or I'll have to get my boss to upgrade my machine....
And I had to check--hey, it's scriptable! The object hierarchy is a little thin (application, document, window--but nothing for objects in the window!), but the verbs are there:
make ()
select ()
revert ()
save ()
set ()
get ()
datasize ()
look to be particularly useful. But we'll need someone who groks the object model really well to write some glue.
While I don't know Frontier I do know COM (and OLE Automation which is really what is involved here). It sounds like on the Mac you've implemented a late-bound mechanism for making method calls on a given class. Presumably (I'm not a Mac programmer) the Apple Events record describes the number of parameters, each parameters type, and somehow packages up the parameter values in a convention that both caller and callee can understand. Also the Apple Event provides the class name and the method name, instead of providing an instance of the class and the method name.
From: yannc@microsoft.com (Yann Christensen);
Sent at Fri, 13 Mar 1998 15:20:56 -0800;
Reaching for COM NirvanaIn the COM world you define a variable number of arguments using a SafeArray of Variants. The VARIANT structure is a union of primitive data-types. It describes which type it contains (possibly empty or an invalid variant) and the data (or a pointer to the data). A SafeArray is an array that understands its upper and lower bounds. This sample will show you how to implement a method with a variable number of arguments:
http://support.microsoft.com/support/kb/articles/q131/0/52.asp
Implementing this can be a little ugly from the C++ point-of-view, however to the Basic programmer it all works like magic. The Basic compiler does all the work of packaging up the arguments into the SafeArray, making the call, and then possibly unpacking the arguments if the callee is also in Basic. Hopefully COM+ will help unify how COM looks to the various development tools that support COM.
The COM mechanism for making late-bound calls is the IDispatch interface. Its basically a more fully-featured version of what your system.verbs.trap mechanism does. However its not useful in your case because each of your "classes" would have to implement IDispatch, but it doesn't sound like they are really COM objects. Instead you are providing the COM interface that does the mapping to whatever interface the "classes" support.
More information you may or may not want to know... There are 3 ways to make a method call in COM: late-bound IDispatch call: All the caller has is an object that implements IDispatch and a method name and some parameters. The caller gives the object the method name and gets back a dispid via IDispatch::GetIdsOfNames. The dispid is an integer that is unique for each method of the interface. Next the caller calls IDispatch::Invoke on the object, first packaging up all the parameters according to the rules of IDispatch. VBScript calls are always done late-bound IDispatch.
early-bound IDispatch call: The type library of the class you want to call a method on is known. The class defines what is called a dispinterface which basically means its an IDispatch-compatible interface defined in a type-library. The GetIdsOfNames step can be skipped and the dispid can be hard-coded into the caller. The rest is the same as a late-bound IDispatch call. The advantage here is that the method call is faster because GetIdsOfNames is skipped (can be significant when making cross-process or cross-machine calls).
vtable call: The object you want to call defines its custom interface as a COM interface. It is compiled in a language that supports the appropriate in-memory binary layout necessary to make a vtable call through the custom interface. This is the fastest way to make a call, but the least flexible since once the interface is published the object can't modify it without breaking existing users of the interface.
COM objects that support vtable and IDispatch calling are described as supporting dual interfaces.
If you're trying to do Windows/COM programming and don't have a copy of MSDN then you should get a copy soon. I keep MSDN running all day long, its the way Microsoft programmers learn to program Windows too!
Good Luck,
Yann Christensen
Visual Basic DevelopmentPS. I didn't actually open the sample above, if its a dud then let me know and I'll see if I can find something else.
Don't define a COM interface! What you need already exists: IDispatch.
From: eau@zip.com.au (Eric Ulevik);
Sent at Sat, 14 Mar 1998 08:57:08 +1000;
The right way to do COM, with variable number of parametersIDispatch is used in VB, VBScript, Microsoft's JScript, etc. This provides all the flexibility you need. It is the right way to build flexible interfaces in COM.
You only need to implement IDispatch::GetIDsOfNames and IDispatch::Invoke. Write directly to the APIs. Do not use MFC or ATL - these class libraries just get in the way.
I believe that your IDispatch-based implementation will end up being much more useful than the Apple Event version.
You asked about Fireworks, and I chose to assume it wasn't a rhetorical question. I downloaded the beta almost as soon as it was released. I think this tool could become a lot more ubiquitous than their Dreamweaver product. It combines a lot of things I have used a lot of different tools to do. It slices images and creates the corresponding table html, which should save those of us that have been doing this by hand a ton of time. I haven't had the time to play with its Javascript and imagemap nor its animation abilities yet.
From: ROcchialini@svi-atl.com (Occhialini, Robert);
Sent at Fri, 13 Mar 1998 16:44:05 -0500;
FireworksIt seems to be the essential and ultimate web developer's graphics tool. The learning curve on it will probably be too great for novice users, but that is fine with me. I plan on playing with it a lot this weekend. What do you think of it?
Partly due to a coworker who's a die-hard Perl-o-phile, and another who's heavily into Tcl/Tk and Expect--but mostly due to playing with Frontier--I'm becoming a strong advocate of scripting. Right now, I'm trying to track down information about scripting support for embedded systems, and haven't had much luck. Perhaps you (or another DaveNet reader) can give me some pointers? I'm looking for a scripting language specifically designed (or at least tailored) for microprocessors running (generally invisibly) in just about every device made today that uses electricity. Such a language would have to have modest memory requirements, and be easily scaled (up or down) as appropriate for any given system.
From: gaulandm@mdhost.cse.tek.com (Mike Gauland);
Sent at Fri, 13 Mar 1998 15:05:58 -0800;
Embedded Scripting Languages?Any information you could provide would be greatly appreciated.
I was going to write about servlets and java.apache.org's work, but someone beat me to it.
From: mnorman@princeton.com (Michael Norman);
Sent at Fri, 13 Mar 1998 12:35:45 -0500;
servlets inside frontierSo let me build on this idea. If Frontier was another server environment that could host servlets, it could really leverage the odb's ease of use and the content management framework. This would be your secret sauce.
If there were simple Java interfaces for Frontier-native code that talked to the odb and could call Frontier verbs, I think you'd end up with place to run servlets that is far more compelling than IIS or even Apache.
That is the problem of Apple, I believe. I have a Mac II from 1987, a Mac IIsi from 1990, a Quadra 950, 2 7100s from 1994 and many more. The only one not in use right now is the Mac II, because I gave it to a friend of mine who never opened the box in which it got shipped.
From: henri@binarycompass.com (Henri Asseily);
Sent at Thu, 12 Mar 1998 17:14:53 -0800;
NY Times articleWhy would I give away machines whose value is so high? The IIsi and Quadra run 4th Dimension and many other programs, and the 7100s are office machines and servers. I pity any company trying to compete in a space where every other competitor sees repurchases every 3 years, while it can't get its customers to buy again.
(And I still have my Apple IIe from 1983, running perfectly fine --albeit with only one disk drive, the other died 3 years ago--. The game Ultima V hasn't lost its magic)
Here's my favorite version for supporting Java plugins in Frontier.
From: hannes@infosys.tuwien.ac.at (Hannes Wallnoefer);
Sent at Thu, 12 Mar 1998 22:38:15 +0100;
Java plugins for FrontierThe Apache group is working on a project at http://java.apache.org to support the Java Servlet framework on Apache servers. I've followed the project for a while, and I'm very impressed with the coding standards. Best of all, the communication between Apache and the Java code is done through a rather simple TCP protocol
http://java.latchkey.com/cvsweb/cvsweb2.cgi/jserv/protocol.txt?rev=1.1.1.1
which makes it quite easy to plug the whole package into other server environments.
The nice things about gluing this into Frontier would be: - it provides the standard API for Java Server extensions (Servlet API), so all existing Servlets will fit in without change. - using raw TCP it would work platform-independently on Mac and Win (while a C-level glue to the Java VM would not) - using TCP you'd be able to run the servlet on any machine (although the servlet runner only accepts connections from the local machine for now) - The software is free.
Of course, performance is a big unknown. It would be nice to have someone step ahead and make some tests. I'm afraid I won't have the time in the next few weeks.
