Ah.

Another approach that I am considering is to uploat the file to the a
HTTP server and have that XML-RPC over to the XML-RPC server.

I already have to do a PHP proxy all my XML-RPC calls because Firefox
doesn't allow javascript to communicate with XML-RPC servers located
on the same host BUT different port number. So, passing the file to
the proxy first is another viable solution.

--- In jsolait@yahoogroups.com, "Jan-Klaas Kollhof" <keyjaque@...> wrote:
>
> yes and no,
>
> form within the browser it is not possible as you cannot read local
> files.
> From within windows scripting it should be possible as long as you can
> read the content of the file, which should work fine for text files
> but for binary it would be a bit difficult. Also the base64 encoder is
> not very fast in JS. The best thing would be to take an external
> program that turns your file into base64 encoded file, read the file's
> content into a string store that string inside an object that has a
> toXmlRpc() method which should return the xml-rpc code for base64
> encoded data, i.e. <base64> contentOfYourData </base64>
>
> you can then send the object as a paramert to the xml-rpc service
> like any other object
>
>
> Jan
>
> PS
> this might work as a data class
>
> var Base64Data=Class(function(publ,priv,supr){
>
>     publ.__init__=function(data){
>         this.data=data;
>     }
>
>     publ.toXmlRpc=function(){
>         return "<base64>"+this.data+"</base64>";
>     }
> });
>
>
> to use it just create a new object:
>
> var data = new Base64Data(base64_encoded_data)
> service.handleData(data)
>
>
> PPS: just found a little bug in the xml-rpc module that prevents it
> from receiving base64 encoded data if it is split  up on multiple
> lines. though sending works just fine.
>

yes and no,

form within the browser it is not possible as you cannot read local
files.
From within windows scripting it should be possible as long as you can
read the content of the file, which should work fine for text files
but for binary it would be a bit difficult. Also the base64 encoder is
not very fast in JS. The best thing would be to take an external
program that turns your file into base64 encoded file, read the file's
content into a string store that string inside an object that has a
toXmlRpc() method which should return the xml-rpc code for base64
encoded data, i.e. <base64> contentOfYourData </base64>

you can then send the object as a paramert to the xml-rpc service
like any other object


Jan

PS
this might work as a data class

var Base64Data=Class(function(publ,priv,supr){

     publ.__init__=function(data){
         this.data=data;
     }

     publ.toXmlRpc=function(){
         return "<base64>"+this.data+"</base64>";
     }
});


to use it just create a new object:

var data = new Base64Data(base64_encoded_data)
service.handleData(data)


PPS: just found a little bug in the xml-rpc module that prevents it
from receiving base64 encoded data if it is split  up on multiple
lines. though sending works just fine.

Is it possible to base64 encode a file on the local disk of the
computer and send it over an XML-RPC using jsolait?

No, there is no module/functionality implemented in jsolait to
intercept the back/forward browsing.

I am currently quite busy and am mainly rewriting some module code in
the experimental branch.
As part of what I do at work with jsolait such functionality might
just become part of jsolait but I have no concrete plans for that.

Sorry,

Jan

Hi everyBody,
   i want to know " how jsolait can be used for Zope Server "...
   please give me some detail , as i am working on Zope ...

   Thanking you all.

Ok, maybe it is a problem. I'll post when I have more info.

On Fri, 1 Sep 2006 8:23:34 -0400, Zachary C. Whitley <mail@...>
wrote:
> Silly mistake by me. Works great.
>
> On Fri, 1 Sep 2006 8:10:22 -0400, Zachary C. Whitley
> <mail@...> wrote:
>> I've been playing with your csvg project. Very cool. I have a small demo
> at
>> http://www.zacharywhitley.com/projects/graph-test01.xhtml
>>
>> You can click and drag the nodes and the edges will follow. I was hoping
>> to eventually put together a graph viewer using GraphML -> XSLT -> SVG
>> but when I put the svg into it's own namespace svg:svg the constraints
>> don't work. I haven't had a chance to look through the code to see how
> it
>> works yet but I thought you'd like some feedback. Thanks for the great
>> package.
>>
>> -Zach
>>
>>
>>
>
>
>

Silly mistake by me. Works great.

On Fri, 1 Sep 2006 8:10:22 -0400, Zachary C. Whitley <mail@...>
wrote:
> I've been playing with your csvg project. Very cool. I have a small demo at
> http://www.zacharywhitley.com/projects/graph-test01.xhtml
>
> You can click and drag the nodes and the edges will follow. I was hoping
> to eventually put together a graph viewer using GraphML -> XSLT -> SVG
> but when I put the svg into it's own namespace svg:svg the constraints
> don't work. I haven't had a chance to look through the code to see how it
> works yet but I thought you'd like some feedback. Thanks for the great
> package.
>
> -Zach
>
>
>

I've been playing with your csvg project. Very cool. I have a small demo at
http://www.zacharywhitley.com/projects/graph-test01.xhtml

You can click and drag the nodes and the edges will follow. I was hoping to
eventually put together a graph viewer using GraphML -> XSLT -> SVG
but when I put the svg into it's own namespace svg:svg the constraints don't
work. I haven't had a chance to look through the code to see how it works yet
but I thought you'd like some feedback. Thanks for the great package.

-Zach

as suggested I opened the wiki a bit again by adding a guest account
just login as guest:guest and you can edit the wiki and add tickets
just like before the wiki was locked up

jan

Hi Jan

Thanks very much for your reply.

> in Internet Options -> Security -> Custom Level -> Misc -> Access data
> sources across domains
>
> That should do it.

Sadly, that didn't do it. I think I may have to give up on this one.

Thanks for your comments on using Jsolait with Windows Scripting Host.

David

Sorry that you did not get an answer earlier, I just got back from a
vacation with no access to a computer for a week :)


> I have looked at the IE settings and it seems to me that the
relevant thing to do was to add the server domain to the list of local
intranet sites. However, it did not fix the problem. If you were
thinking of another setting please let me know.

enable:
in Internet Options -> Security -> Custom Level -> Misc -> Access data
sources across domains

That should do it.


> By the way, can I use the jsolait xmlrpc library in scripts running
in Windows Scripting Host?

yes that works. Use the jsolait.wsf file to run your script and all of
jsolait's functionality is available.
cscript.exe /nologo "c:\path_to_jsolait_folder\jsolait.js"
"file://path_to_script\your_script.js"

it should also be possible to include jsolait in a wsf file. but you
would then need to make sure certain jsolait properties have to be set
for module import to work. (I should write some docs for that)


Jan

Forgive my insolance, and my ignorance.

It seems that in IE, the handling of namespaces is behaving
differently in my app.

That is,

   var oOo = dom.getElementsByTagName("blah")

works in FF, but not in IE.

This does work in IE though:

   dom.getElementsByTagName("ack:blah");

Not entirely sure why, not entirely sure I care either, just that its
no problem with JSOLAIT :)

thanks
Mark


--- In jsolait@yahoogroups.com, "Mark" <alienjazzcat@...> wrote:
>
> Has anyone experienced this?  I suspect (and have tweaked) security
> settings in IE related to ActiveX, but I just can't seem to get IE to
> parse XML.
>
> The XML module does not throw exceptions while creating one of the 3
> "IE" ActiveX controls, but nothing gets loaded either into the 'obj'
> variable.
>
> Any ideas?  thanks
> Mark
>

Has anyone experienced this?  I suspect (and have tweaked) security
settings in IE related to ActiveX, but I just can't seem to get IE to
parse XML.

The XML module does not throw exceptions while creating one of the 3
"IE" ActiveX controls, but nothing gets loaded either into the 'obj'
variable.

Any ideas?  thanks
Mark

Hi Jan

Thanks very much for your reply...

> sounds like a security issue
>
> In IE you can set a preference to allow scripts to access other
> domains then the one the page originated from. In FF it is not
> possible and all requests will have to go to the same domain the
page
> is loaded from.
> It is annoying but there are good reasons for that.

The script is loaded from my local PC but accesses a company server
running Apache. So I guess they are on different domains (sorry to be
vague on this point but my understanding of these things is limited).

> A solution is to have a XML-RPC proxy set up on the server the pages
> are coming from and that proxy will make requests to the real one.

Thanks, but that is probably rather an elaborate solution for what I
am trying to do.

I have looked at the IE settings and it seems to me that the relevant
thing to do was to add the server domain to the list of local
intranet sites. However, it did not fix the problem. If you were
thinking of another setting please let me know.

> If that is not the issue, could you give the complete error trace?
> it should be in errorObj.trace or use errorObj.toTraceString()

I assume that errorObj is the exception object thrown by the login
method? In that case, the complete trace is:

"RequestOpenFailed [module 'urllib' version: 1.1.3]:
     Opening of HTTP request failed. Access is denied."

Please let me know if you have any other questions or if I have
misunderstood your message.

By the way, can I use the jsolait xmlrpc library in scripts running
in Windows Scripting Host?

Thanks again for your help.

David

sounds like a security issue

In IE you can set a preference to allow scripts to access other
domains then the one the page originated from. In FF it is not
possible and all requests will have to go to the same domain the page
is loaded from.
It is annoying but there are good reasons for that.

A solution is to have a XML-RPC proxy set up on the server the pages
are coming from and that proxy will make requests to the real one.

If that is not the issue, could you give the complete error trace?
it should be in errorObj.trace or use errorObj.toTraceString()

Jan

Hi

Firstly, thank you for making available the jsolait library.

I want to use the XML-RPC jsolait library to connect to our 'JIRA'
issue tracking system (www.atlassian.com). I have checked that JIRA
responds to XML-RPC requests using a Java Webstart application from
Atlassian. It responds correctly.

Atlassian have an example JavaScript script that connects to JIRA
using XML-RPC and which uses jsolait. They claim it works only with
Safari and 'doesn't work in Firefox or IE, due to security and other
issues, all fixable'. We are a PC-only house so don't have Safari.
Therefore, I'm trying to get the script to work with either IE7 or
Firefox 1.5. However, the script works with neither currently. The
script raises an exception at the following line:

var server = new xmlrpc.ServerProxy('http://<Jira Url>'/rpc/xmlrpc',

['jira1.login',"jira1.getProjects","jira1.getVersions","jira1.getCompo
nents","jira1.getPriorities","jira1.getIssueTypes","jira1.createIssue"
]);

The exception message is:

RequestOpenFailed [module 'urllib' version: 1.1.3] Opening of HTTP
request failed.

Please can anyone suggest what may be wrong or how to get more
information about the problem?

Thanks

David

Hi everone!

I noticed having keep-alive enabled in Apache delays the method
response by the keep-alive timeout. The callback function does not get
called until the FIN/ACK response has been received (i.e. after 15
seconds using Debian Apache 2.0.54 default timeout.) Disabling
keep-alive in the Apache configuration I get <1s responses, which is
the performance I'm looking for.

Does anyone know how to handle this without disabling keep-alive in
Apache?

Running Debian Sarge 3.1, Apache 2.0.54, Firefox 1.5.0.4.

Any help welcome. Thanks!

It looks like that IE does not have the problem earlier described.
Though firefox does, so it is a no go for that solution.

I played some more with the module creation code and checked in a new
version into svn.
The current module does the following when creating a module.
It analyses the source to extract all imprt(...) statements.
Once all dependencies are resolved. A new module is created by
wrapping the module's source in a function. All imported objects are
added to the  function parameter lists, thus exposing them as local
objects to the module. Other objects like mod, id(), str(), repr(),
Class, ... are also added to the function parameters and thus become
local objects for the module.
The constructed wrapper function is then called and the module has the
chance to initialize itself and add objects to it's public interface
(mod).

Not much changes compared to jsolait's original module structure:

* all imprt() statements are resolved before the module is run
* imprt("itertools:*") is possible to import all objects form a module
* imprt("itertools:iter, zip") is possible to imprt specific objects
form a module
* module creation can be implemented to run asynchronously because
dependencies are resolved before module creation



Jan

I just got some results from playing with the experimental branch:

One feature was to expose new objects to a module's local namespace.
This seems to work fine with one exception and that is in the catch block.

Here an example that shows the problem:
var p = {test:1234}

with(p){
     p.f=function(){
         try{
             print(test)
             throw "123";
         }catch(e){
             print(test)

         }
     }
}
p.f()


inside teh catch block 'test' is not visible anymore though it is
anywhere else in the function p.f.

This may render the import mechanism in the experimental branch useless.
A similar mechanism can be used to make public module objects local.
e.g.:

with(mod){
    mod.f1=function(){
    }

    mod.f2=function(){
       f1()l
    }
}

This is what jsolait actually does when creating new modules.
Plus another with statment for the local scope where all imports are
attached to.
Unfortunatly that does not work inside any catch statement :(.
I can still remove all but the jsolait object from the global
namespace but imports would have to be done the same as before.

Jan

I have created a new branch: http://svn.jsolait.net/branches/experimental/

Things I have implemented in that branch:

* jsolait now only exposes a single global object and that is jsolait

* all modules must be loaded using jsolait's module loading mechanism

* module sources do not use Module(...) any more

* modules have access to all jsolait built in objects(str, repr,
imprt, ...) as if they were local object.

* imprt() calls do not return anything, rather they extend the modules
namespace (adding all imported objects into the modules runnung scope.

* partial module import e.g. imprt("itertools:iter") or
imprt("itertools:*")

* asynchronous module import and module loading using the asyncimprt
module



Have a look in the lib folder to see how module source files look like.

To use the new code in html, include the core jsolait.js file in the
html and call:
var mod = jsolait.loadModule(moduleName)
to load your startup module.

if you want all modules to be loaded asynchronously then first load
the asyncimprt module and use it's loadModule() function:
var m =jsolait.loadModule('asyncimprt');
m.loadModule('foo', function(m,e){
   //module has been loaded or an error is stored in e
   alert(m + " " + e)
});

all imprts done in foo will use the asyncimprt to load dependent modules.


have a play with it and let me know what you think,


Jan

Hi,

Exactly there are libraries out there but the standards and so on are
not that I want.
I try to run DoJo in SVG but that isn't working either.
We now use the Kevlindev routines for handles of drawing objests. But
it is not properly OO (globals around no namespace) on top of that we
put some global routines for drawing dashed rectangles (selecting an
area) and selecting multiple objects. Of couse this is also ugly.
So I was thinking of a better event mechanism like the Yahoo stuff for
example but their libs doesn't run in Adobe so I was a little bit
stuck and rebuild 2d stuff of Kevlin (but still use his intersect
framework (slow for complex objects)).

John
--- In jsolait@yahoogroups.com, "Jan-Klaas Kollhof" <keyjaque@...> wrote:
>
> Hi,
>
> > We have an application running in IE and Firefox using native SVG
> (open modeling). In firefox I can use YUI library for the event stuff
> in SVG it won't load the jsolait libraries properly (becauase not made
> for Adobe SVG plug in).
>
> What do you mean by "won't load properly", what daes not load and what
> errors do you get, does the core part load OK?
>
> In ASV you won't be able to import modules the same way that you would
> in HTML as ASV does not have synchronous HTTP request to load the
> module source on demand. You would need to ref. the module's source
> files in your SVG document using the script element. This will change
> once I implemented an asynchronous module loader in jsolait.
>
> The other thing I can see is that YUI may clash with jsolait due to
> maybe common global objects or prototype properties that may not be
> compatible. I am in the process of removing all global objects from
> jsolait except the jsolait object itself. This should make it more
> friendly torwards other framworks.
>
>
> > Is there a way to work this out.
>
> Not sure, I would need more info on what exactly the problem is, maybe
> an example.
>
> > Does jsolait handles event in a nice way and can it run in both
> environments (SVG plugin Adobe and Firefox native).
>
> There is no special eventhandling in jsolait.
>
> > Are you thinking of making widgets in jsolait or do you want
> combining with other libs.
>
> If I had the time, I would.
> There are a number of good GUI toolkits out there. I may not agree
> with their package/module handling and how they do OOP in JS, but
> they seem to be doing a fine job with UI components.
>
>
> Jan
>

Hi,

> We have an application running in IE and Firefox using native SVG
(open modeling). In firefox I can use YUI library for the event stuff
in SVG it won't load the jsolait libraries properly (becauase not made
for Adobe SVG plug in).

What do you mean by "won't load properly", what daes not load and what
errors do you get, does the core part load OK?

In ASV you won't be able to import modules the same way that you would
in HTML as ASV does not have synchronous HTTP request to load the
module source on demand. You would need to ref. the module's source
files in your SVG document using the script element. This will change
once I implemented an asynchronous module loader in jsolait.

The other thing I can see is that YUI may clash with jsolait due to
maybe common global objects or prototype properties that may not be
compatible. I am in the process of removing all global objects from
jsolait except the jsolait object itself. This should make it more
friendly torwards other framworks.


> Is there a way to work this out.

Not sure, I would need more info on what exactly the problem is, maybe
an example.

> Does jsolait handles event in a nice way and can it run in both
environments (SVG plugin Adobe and Firefox native).

There is no special eventhandling in jsolait.

> Are you thinking of making widgets in jsolait or do you want
combining with other libs.

If I had the time, I would.
There are a number of good GUI toolkits out there. I may not agree
with their package/module handling and how they do OOP in JS, but
they seem to be doing a fine job with UI components.


Jan

Hi,

We have an application running in IE and Firefox using native SVG (open
modeling). In firefox I can use YUI library for the event stuff in SVG it
won't load the jsolait libraries properly (becauase not made for Adobe SVG
plug in). Is there a way to work this out. I like the YUI stuff for their
widget and so on I dont like the idea for developing and testing twice (but
maybe there is no solution for this).
Does jsolait handles event in a nice way and can it run in both environments
(SVG plugin Adobe and Firefox native).
Are you thinking of making widgets in jsolait or do you want combining with
other libs.

John


>From: "Jan-Klaas Kollhof" <keyjaque@...>
>Reply-To: jsolait@yahoogroups.com
>To: jsolait@yahoogroups.com
>Subject: [jsolait] module construction
>Date: Fri, 14 Jul 2006 16:44:26 -0000
>
>Another idea I have been playing with.
>
>I have been thinking about dropping the Module(...) constructor or
>makign it optional.
>Lets say modules are loaded only using the module loading mechanism
>provided by jsolait. Their names map to the file names as it is now.
>Inside the running module scope/name space there are some special
>objects, basically all objects that are now globaly available in jsolait.
>The Module(...) constructor would not be needed anymore because the
>scripts are not refferenced using script tags but are loaded by
>jsolait and jsolait would take care of providing all required objects
>to the module's runtime.
>
>This would mean that jsolait could be written without any global
>objects at all and yet inside a module one would have local objects
>that would replace the now global ones. The imprt statement would also
>be able to extend the module's local namespace with objects allowing
>statements like imprt("iter:*") which would import all items from the
>iter module and expose them in the module.
>
>This would allow jsolait to play nicer with other libs as the only
>global object it would expose would be the jsolait one itself.
>
>It would make it impossible though to create modules inside a script
>tag unless I still provide the Module(...) wrapper that would become a
>bit more ugly as I would need to provide a way for the local namespace
>handling...
>
>I hope I am making sense.
>Here just an example how a new module would look like:
>-------8<--------------
>imprt('iter:*');
>
>priv.foo = "bar";
>
>publ.spam = function(n){
>    iter(n, function(a){
>        print(a + foo);
>    });
>}
>
>spam();
>-----8<---------------
>
>spam() would be a public property of the module and foo would be
>private. all items imported from the iter module are attached to the
>local namespace of the module.
>
>
>
>What do people think?
>
>Jan
>
>
>
>
>
>
>
>
>
>

Another idea I have been playing with.

I have been thinking about dropping the Module(...) constructor or
makign it optional.
Lets say modules are loaded only using the module loading mechanism
provided by jsolait. Their names map to the file names as it is now.
Inside the running module scope/name space there are some special
objects, basically all objects that are now globaly available in jsolait.
The Module(...) constructor would not be needed anymore because the
scripts are not refferenced using script tags but are loaded by
jsolait and jsolait would take care of providing all required objects
to the module's runtime.

This would mean that jsolait could be written without any global
objects at all and yet inside a module one would have local objects
that would replace the now global ones. The imprt statement would also
be able to extend the module's local namespace with objects allowing
statements like imprt("iter:*") which would import all items from the
iter module and expose them in the module.

This would allow jsolait to play nicer with other libs as the only
global object it would expose would be the jsolait one itself.

It would make it impossible though to create modules inside a script
tag unless I still provide the Module(...) wrapper that would become a
bit more ugly as I would need to provide a way for the local namespace
handling...

I hope I am making sense.
Here just an example how a new module would look like:
-------8<--------------
imprt('iter:*');

priv.foo = "bar";

publ.spam = function(n){
    iter(n, function(a){
        print(a + foo);
    });
}

spam();
-----8<---------------

spam() would be a public property of the module and foo would be
private. all items imported from the iter module are attached to the
local namespace of the module.



What do people think?

Jan

I have been thinking a while about asynchronous module loading/import
and would like to get some feedback on the subject.

The advantage is that module imports would run in the background and
would not block the browser. One would also be able to hook into the
import mechanism and display status information about what is
happening in the background. This would mean that module
sources/scopes could only run after all dependencies are resolved.

The solutions may be a bit tricky.
1. one could parse a module's source for imprt(...) statements and
resolve the dependencies by loading the required module source and
repeat the parsing untill everything is resolved.
This requires either a strict syntax or a good/fast parser to find the
imprt() statements.

2. One could just run the module's source and let the imprt() statment
throw a Dependency exception which signals the module loader to put
the module source on hold and run it again once the modules it depends
on are loaded and run sucessfully...
This should work as long as all imprt() statements are on the top
level of the module, i.e. not inside functions.

3. module dependencies are expressed in the Module(...) statment and
can therefore be resolved before the module scope is run.
Like in 2. it would make imprt() statements inside functions impossible.

4. imprt() statement has a callback which is run after a successful
module import. Again like in 2. and 3. it would not work inside
functions very well unless these too work only with callbacks and
don't return a value themsleves.


What do people think?

Jan

I believe 2.0 is where I want it to be and I'd like to close the mile
stone and move forward to the next one.
This means that jsolait 2.0 is feature complete and the API is frozen.
The only code changes will be bug fixes.


Jan

> > There's a plugin available for trac that might help with spam...

This needs version 0.10 of trac. I will have a lock at it. I might
just ditch the debian package and install trac from source.

> People who don't feel like fiddling with their install also sometimes
> publically post login information that anyone can use, because
Spammers  will never look closely enough to find the information.

It seems that the spam is automated and targeted at "open" trac systems.
So, this would be an option but I am not sure how I feel about it.

Christopher Hiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jan-Klaas Kollhof wrote:
>
>>I had to lock down the wiki for now :(
>>Until a solution is found I have to lock down the wiki.
>>Thanks to everyone who helped with spelling and grammar and removing
>>spam.
>>
>>Unfortunatly the spam has gotten to a point where it not only adds
>>hidden content but completely destroys the exsisting content of the
>>pages. I am very sad about this as I wanted the site to be open for
>>people to edit.
>>If you do want to work on teh site, let me know and I will register
>>anyone who likes.
>>
>
>
> There's a plugin available for trac that might help with spam...
>
> http://trac.edgewall.org/wiki/SpamFilter

People who don't feel like fiddling with their install also sometimes
publically post login information that anyone can use, because Spammers
will never look closely enough to find the information.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan-Klaas Kollhof wrote:
> I had to lock down the wiki for now :(
> Until a solution is found I have to lock down the wiki.
> Thanks to everyone who helped with spelling and grammar and removing
> spam.
>
> Unfortunatly the spam has gotten to a point where it not only adds
> hidden content but completely destroys the exsisting content of the
> pages. I am very sad about this as I wanted the site to be open for
> people to edit.
> If you do want to work on teh site, let me know and I will register
> anyone who likes.
>

There's a plugin available for trac that might help with spam...

http://trac.edgewall.org/wiki/SpamFilter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtpQ4yRACYsTiPEMRAjWcAJ46qKMAq5JpOlhjCGMMRcPL6pZbrQCePsXs
DKo0Sgps5rGo9iyHPhaiOxU=
=A9OG
-----END PGP SIGNATURE-----