xmlrpcflash-development — A developers list for core development of the xmlrpcflash client library.

[xmlrpcflash-development] Greetings!

[Ed C. <ed-...@gr...>]

Just wanted to say a quick hello.

I've got a few flash projects going on right now, and hopefully will be 
having some time to play around with the xml-rpc lib.

I got your latest source Isaac.  Do you have a quick example of it in use 
just so I can start to grok the syntax?

Looking forward to a great library (with a neat logo too)!

Cheers!

-e-


-- 
Green Graphics   :::   Print and Web Design   :::   510.923.0000 

[xmlrpcflash-development] Re: Status Report- xmlrpcflash

[Isaac L. <is...@st...>]

Hi Patrick,

On Wednesday, November 6, 2002, at 03:19 AM, Patrick O'Lone wrote:

> Parse method bug? You mean the alternative code I sent which emulates
> SAX-style derived parsers?

Yes.  That is what I meant.

>> 2) familiarizing myself with the admin tools for SF (yikes- sf is
>> surely clumsy, but free...)
>
> Yeah, not what you expect the first time through. ;-)

Ugh...  Yep.  Of note- I've been investigating ways of making CVS 
commits and checkouts from a web browser, with administrative 
controlled access etc... for the guys I'm working for right now, but 
haven't had any good results.

>>
>> IF PATRICK IS OK WITH THIS LOGO (i.e. do you like it?), I'd like to
>> begin using the graphic in all website materials, and demo .fla files.
>> (I think it's pretty great- simple, sexy, and easy to impliment in
>> various formats.)
>>
>
> You got my approval +1. Seems sweet too me.

Great!

>
>> ####################
>> Regarding our Roles:
>>
>> First off, Patrick, I very much hope none of this is steping on your
>> toes here.
>
> Nope, your not. I gave full access because of my conversation with 
> you. I
> feel confident your giving it 100% of your effort, and open-source 
> implies
> effort on many individuals, not one. Your an equal as far as I'm 
> concerned.

Ok.  Cool.

>>
>> Secondly, I'd really like to get a bunch of actionscript/flash gurus
>> involved more directly, so this can become the best darn xmlrpc client
>> ever.
>
> Actionscript isn't my native language, so if you think we can benefit, 
> by
> all means give them a show. You never know what you'll learn from 
> someone
> else's perspective, and I'm interested in two things:
>
> (1) speed
> (2) ease-of-use

Noted, and I agree.

>
>> Thridly, I'd like to get more xmlrpc users from different languages
>> involved for input, as well as to eventually provide examples with
>> server-side code in various common languages (perl, php, python, java,
>> etc...)
>
> An ironic thing about this. I was asked for information for inclusion 
> in the
> release of an O'Reilly book on XML-RPC. Unfrotunately, time was 
> limiting and
> they wanted something more stable, so it never flew. I guess there's 
> always
> the 2nd edition ;-).

For sure!  I have been using that book- it's a great resource.

>>
>> As time continues, if it's OK, I'd love to get more people involved, 
>> to
>> spread busywork evenly (which would mean I'd eventually like to be 
>> able
>> get more members onboard with varying degrees of access...)
>
> I don't know if all those roles are necessary. Since Flash isn't really
> available for Linux, I don't know if packages are needed, for example.
> Requirements engineering seems to broad to me (the requirements are 
> pretty
> specific in this, an XML-RPC library), so beyond perhaps feature 
> requests,
> this seems like overkill to me.

Understood.  No need to overcomplicate.


>>
>> As the biggest users of flash are visual/multimedia oriented folks,
>> those outside of open-source/programming I've showed Sourceforge to 
>> has
>> a hard time using it.  The SF website, and many of the ways of working
>> are foreign, (actionscript is not even listed as a programming
>> language), and this makes us miss out on a lot of GREAT actionscript
>> programmers who could really help (and would).
>
> I agree. Originally, I had posted some information on flashkit.com. 
> Since I
> haven't used Flash much in recent times, it may not be listed anymore.

Ok- One of the guys I work with/for is a hardcore Flash designer.  He's 
pretty down with where to go for help- and also where to go to get 
folks who'd be interested in using/extending the library.
There is another sf actionscript project gaining some serious steam, 
(i.e. the flash communities are really exited about it...)

http://sourceforge.net/projects/fasl

This not only looks to be a really great project, (35 people working on 
it already!), but it is a collection of a lot of well-known 
actionscripters.  Anyhow, SF is getting actionscripters... <g>

>
>> So, this was why I put up the job posting for a logo to be designed,
>> (visual identity reinforces a project to right-brained programmers).
>>
>> Additionally, I think a lot of confusion can be avoided by creating a
>> simple website on sf, something to organize the project and
>> documentation off of the main SF project page.
>> This will take a bit of work, but I think it's very important as the
>> project proceeds- and I'd be glad to start it off-
>
> Again, I concur. Though, this time, I wonder if the documentation 
> should be
> written in DocBook, so we can create HTML, PDF, and CHM versions of it.

OK with me- DocBook is a format I don't know much about, but I'll look 
into it a bit this afternoon-
Additionally, the FASL project, as their first task, has taken it upon 
themselves to define some standards of working with actionscript 
(really tight, these folk...),
as well as defining the method of documentation- from within Flash 
itself, using the Actionscript Library (!!!!)
http://sourceforge.net/docman/display_doc.php?docid=13619&group_id=65397

This is really cool- and I'm sure that any of our docs (and 
actionscript) could eventually fit into their nicely defined schema, 
making the xmlrpc library nicely accessible directly from within 
flash...  Hmmm... Future thought? (mabye once their dust settles a bit?)

>
>> Here is a basic sketch of how I'd like to organize the website:
>>
>> ---------------------------------------------------------------
>> http://xmlrpcflash.sf.net | proposed starting website structure
>> ---------------------------------------------------------------
>> download
>>      download current stable SF release
>>      browse/download CVS files (download CVS for development version)
>>
>> documentation
>>      license
>>      Link to Doc Manager
>>      Diagrams and tutorials
>>
>> getting Involved
>>      general instructions on how to get involved
>>      links to various SF instructions
>>
>> interaction (development on mailing list, public discussions on public
>> forum)
>>      link to SF developer mailing list (great for passing code 
>> snippets)
>>      link to SF discussion forums
>>        (flash developers seem to like forums
>>         as they provide a bit of annonymity)
>>
>> links
>>      links to related xmlrpc resources
>> ---------------------------------------------------------------
>> ---------------------------------------------------------------
>>
>>
>>
>>
>>
>> ######################
>> Regarding the License:
>>
>> On Tuesday, October 8, 2002, at 09:32 PM, Patrick O'Lone wrote:
>>> Actually, the license has to change. The next release I was thinking
>>> about
>>> using the LGPL so that commercial applications could use it without
>>> worry.
>>> While I agree with the Open Source Initiative, most companies don't
>>> have the
>>> time nor resources to write ActionScript files for every application
>>> that
>>> would make use of it. In addition, it creates a severe limitation for
>>> the
>>> use of the code. With the LPGL, the code can be used in either or
>>> without
>>> the restriction of having to open source the entire application with
>>> which
>>> it would be compiled with.
>>
>> Great.  Perfect.  If it's OK with you, I'd like to go ahead and change
>> the license in the distribution, and post it as an 0.5.1 Alpha- (as it
>> would be a good moment for me to get the swing of both the CVS commit
>> process, and the SF distro upload process.)
>>
>> Additionally, I'd like to make a motion to change the actual filename
>> of the actionscript library-
>> from xmlrpc.as to xmlrpclib.as
>>
>> Reason being, xmlrpclib is a bit more natively descriptive, and also,
>> the other library out there, (the one by Pedro Ornealias), is named
>> xmlrpc.as as well.  I was just thinking it would avoid confusion for
>> folks trying out both libraries.
>>
>> (Historically, a similar naming difference happened in 2 different
>> python xmlrpc libraries- and xmlrpclib.py was eventually brought into
>> python's core)
>
> If you think that will help. One thing, however. I'd like to get a 
> working
> version of the SAX-based parser version and then switch library names. 
> It
> seems pointless to release a version just to change the name of the 
> file. I
> think we should poll ideas on what the next version of the client code
> should do (and act), make the fixes, and then release the next update 
> with
> the new name. I have a couple of reasons for doing this:
>
> (1) Anyone using the existing code-base has a reason to upgrade
> (2) Actual documentation that reflects the new working version
> (3) Some security in knowing that it works

OK- this makes complete sense.
Re. taking a poll-
Did you want to do this informally, (emailing those you know are using 
it etc...), or would you like to make a sourceforge survey?  I just 
went in and turned back on the SF survey tool- but didn't add any 
surveys...

In the meantime, with new working files, I was wondering:
Should we:
1) use the SF cvs for working files
    (I'm a bit all thumbs with cvs, but I'll brush up if need be)
2) use the dev mailing list to share files, as well as working code
3) do something else for organized file sharing (of working files)

note on #3:
I could set up a dav-mountable volume on a server of mine relatively 
quickly, so we could all mount a shared directory on our desktops- 
mac/win/*nix, respectively... as well as getting to it via FTP, and 
through a web browser.
Additionally, (as I'd run it off of a Zope), the Zope would keep a 
history on every file uploaded, so diffs can be performed through a web 
browser interface etc...

This is common practice for how I work with my designer clients and it 
works pretty well there-

> I think we have some great
> things ahead of us. Thanks for all your effort. ^_^
>

Rockin- I'm super energized here too...





   Isaac Levy
+ Office of Structured Systems
   http://structuredsystems.net

[xmlrpcflash-development] Patrick's patch code for the response parse bug

[Isaac L. <ik...@vi...>]

Just thought I'd post this code here, for the record-
It is a Patch for the 0.5 Alpha release:

> On Tuesday, October 8, 2002, at 09:32 PM, Patrick O'Lone wrote:
>
>>
>> Actually, the unreleased API simply abstracts more from the
>> implementor by
>> auto-calling most methods implicitly. In addition, some clarification
>> of the
>> types created and bug fixes were implemented. But now that I've heard
>> more
>> about your woes with the engine's getResults() method, I'm wondering
>> if the
>> best solution is to simply force the developer to implement callbacks.
>> The
>> idea would be something like this:
>>
>> EchoClient.prototype.__proto__ = XMLRPC.prototype;
>> EchoClient.prototype.startElement() = function ( name, attrs ) {
>>
>>    // Handle structs how I see fit
>>
>> }
>>
>> EchoClient.prototype.endElement() = function ( name ) {
>>
>>   // Handle array elements how I see fit
>>
>> }
>>
>> EchoClient.prototype.dataElement() = function ( data ) {
>>
>>   // Deal with data elements
>>
>> }
>>
>> objEchoClient = new EchoClient();
>>
>> Perhaps, the XMLRPC object would simply call these methods of itself,
>> with
>> the assumption the developer is to implement these by inheriting the
>> XMLRPC
>> class and defining these methods, then instantiate that object to
>> process
>> the XML-RPC message. The object would still call getResults(), but the
>> method would now run parse() and call the subclass's overloaded 
>> methods
>> instead (we'd set defaults for debug purposes).
>>

A sample rework of Parse() (it's MUCH simpler IMHO) would be:

function Parse ( Node )
{
     if (Node.nodeType == 3) {

        // Data elements call the dataElement() method as overloaded
        // by the inherited class.

        this.dataElement(Node.nodeValue);

     } else if (Node.nodeType == 1) {

        // Tag elements call startElement() first, and pass any 
attributes
        // that exist to that method as well.

        this.startElement(Node.nodeName, Node.attributes);
        for (var i in Node.childNodes) {

            // Parse each child node that this node has.

            this.Parse(Node.childNodes[i]);

        }

        // End this element by calling the overloaded endElement() method

        this.endElement(Node.nodeName);

     } else {

        // Something has gone terribly wrong - this isn't
        // a possible state!

        return false;

     }

     return true;

}

Regards,

-----------------------------------------

Patrick O'Lone
Aeon Solutions, Inc.