AltME groups: search

...but you probably mean api calls to it

Reichart - AltME did not developed into open API framework, so I 
really can't see much differece to IRC e.g., whish is, client scriptable, 
provides security if needed, moderated discussions ...

I'm not resisting here keep in mind, just saying that my goal is 
to put energy into one messaging system that is wrapped in an API 
that everyone can use.

my goal is to put energy into one messaging system that is wrapped 
in an API that everyone can use


that requires me to ask whether you are dropping AltME or whether 
QTask will eventually use an AltME like frontend?

Anton, error #4124 is not a filesystem problem. I replicated it here, 
on NTFS, in a directory that I have permission to do anything. NTFS 
supports changing the modification date of directories - I have an 
Explorer shell extension that does just that, as well as a command 
line touch utility. REBOL can change that attribute on files, but 
not directories. REBOL is probably hust using the wrong API.

different API - maybe the same goes with TimeZone info .... Ladislav 
found new pointer .... currently under investigation ...

and invisible datatype... with accessors, I could code a liquid api 
which is completely hidden from users... totally non-aggressive to 
the way they currently code and yet still allow custom types of liquid, 
just by changing how the accessors are built.

There is a difference between the IMAP protocol itself (RFC 2060) 
and the imap:// URL scheme (RFC 2192). At this time REBOL only supports 
the imap:// URL scheme, which has a subset of the full IMAP protocol 
functionality. It handles mailbox lists, message lists, retrieving 
and deleting of messages, and message searches, i.e. it is API-compatible 
to pop://, with added support for multiple mailboxes and searches. 
Move/copy/rename and other administrative IMAP functions are not 
specified in RFC 2192 and not supported by REBOL's imap:// scheme 
at this time.

Well, I am stuffing around with files in C at the moment. I will 
see if it can be done with Windows api.

http://vbnet.mvps.org/index.html?code/fileapi/folderdatetime.htm
for visual basic, googled "windows change directory date api"

Graham, in the old days you would use the Escape+passthrough API, 
but that's been frowned on for quite a while now. Have you tried 
writing to %//PRN ? With more API work (OpenPrinter), you can use 
spooler functions like EndPagePrinter or WritePrinter too.

Doesn't look like it. I think file skip was removed because of moving 
to new Windows api.

sunanda, you might want to add an "extension" section to rebol.org 
where we may contribute C/C++ code to rebol.org... what do you think?


for tutorials and small projects it might be very usefull as a tool 
to help out other people into understanding how to use the extension 
API.

I have uploaded a new version of simple-test.r to the Script Library. 
The main changes were the addtion of some new assertions and a re-structuring 
of the code to provide an API for the function which evaluates test 
cases.


The assertions added are : equal with tolerance, not equal, not error, 
same, and not same.

a picture of  MDP-GUI 1.3 including the render API of Ashley/Gabriele 
http://shadwolf.free.fr/mdp-gui13.r

Linux does not have any api to get to the ttf from the font name.

Task-Master Service documentation and Modules API : http://www.softinnov.org/rebol/task-master.html

About UniServe, I'd like to include some protocols/services done 
by Graham in UniServe's distribution (if he agrees). If anyone has 
done some protocols or services implementations that would be useful 
to others, please post some info about them here. I'll be also glad 
to have from UniServe's users some feedback about UniServe's API, 
missing features that you would like to be included, etc...

In fact, from what I know about LNS, they could be implemented above 
UniServe using UniServe's service API.

yes, that might be the interface I asked about last time Carl was 
here. He told me he planned to provide API to rebol internals, but 
he told something like it could become complex (even security was 
mentioned iirc) and that rebcode replace it, so ....

Volker, I know, but some time ago I though that e.g. you have rebol 
block for e.g. and I thought that there might be some api, kind of 
DOM, so that from C library, you would access it via such structure 
and you would manipulate rebol datatype value directly

I've done that in the past, the problem when using direct API calls 
is passing pointers and stuff, remember you need to create a main 
loop to pool events  and messages, it's a pain... i've some code 
that does this, but remember that this old style is gone on vista 
gfx.

Anton, can you see anything wrong with this ... crashes Rebol

rebol []


; download the skype4com dll from https://developer.skype.com/Docs/Skype4COM/Start
; and register the library
; regsvr32 skype4com.dll

; example of using sms
; https://developer.skype.com/Docs/Skype4COMLib/Sms_vbs

COMlib: do %comlib.r
COMlib/initialize

do bind [
	oSkype: CreateObject "Skype4COM.Skype" 

 oSMS: GetObject [ oSkype ".SendSms( %s, %s)" "+12345679" "Hello!" 
 ]

] COMlib/api

This should send a SMS using the Skype installed on your PC.

I posted a question on the Skype API forums ... not that I am expecting 
a reply :(

COMlib: do %comlib.r
COMlib/initialize

if error? set/any 'err try [
	do bind [
		oSkype: CreateObject "Skype4COM.Skype"
		if -1 <> res: GetInteger [oSkype "Client.IsRunning"] [
			CallMethod [oSkype "Client.Start()"]
		]

  cUserStatus_Offline: GetInteger [oSkype ".Convert.TextToUserStatus(%s)" 
  "OFFLINE"]
	] COMlib/api
] [
	probe mold disarm err
]

Graham - actually I thought about "porting" Rails to rebol and calling 
it "rebol on trails" :-) But last time looking at rails api, it is 
already large jog done. OTOH we would only clone API that already 
exists ... dunno ....  because whole web 2.0 mess is here, to be 
finally able to do what REBOL/View can do, just using browser ...

The good part is that you don't need to do any memory management. 
But I think you need to be familiar a bit with the Cocoa API, because 
F-Script wraps it into an smalltalk syntax.

Google axes search API - http://www.osnews.com/story.php/16769/Google-Axes-Search-API

some ppl speculate it is because they had no income from it. It is 
going to be replaced with AJAX. Maybe they want to force ppl to "display" 
the result somehow, just to see advertisements? If so, it is stupid. 
I would better pay for such service with API, then was being forced 
to use some obscure aproach ....

is .NET complete API replacement for Win32? I thought it is kind 
of virual machine (competition to JAVA), and hence for kind of internet 
ready apps, but not system wide apps?

I'm thinking about updating to the newest SQLite version. And I just 
read there is a new API which should be used.


The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are 
recommended for all new programs. The two older interfaces are retained 
for backwards compatibility, but their use is discouraged. In the 
"v2" interfaces, the prepared statement that is returned (the sqlite3_stmt 
object) contains a copy of the original SQL. This causes the sqlite3_step() 
interface to behave a differently in two ways:


If the database schema changes, instead of returning SQLITE_SCHEMA 
as it always used to do, sqlite3_step() will automatically recompile 
the SQL statement and try to run it again. If the schema has changed 
in a way that makes the statement no longer valid, sqlite3_step() 
will still return SQLITE_SCHEMA. But unlike the legacy behavior, 
SQLITE_SCHEMA is now a fatal error. Calling sqlite3_prepare_v2() 
again will not make the error go away. Note: use sqlite3_errmsg() 
to find the text of the parsing error that results in an SQLITE_SCHEMA 
return. 


When an error occurs, sqlite3_step() will return one of the detailed 
result-codes like SQLITE_IOERR or SQLITE_FULL or SQLITE_SCHEMA directly. 
The legacy behavior was that sqlite3_step() would only return a generic 
SQLITE_ERROR code and you would have to make a second call to sqlite3_reset() 
in order to find the underlying cause of the problem. With the "v2" 
prepare interfaces, the underlying reason for the error is returned 
directly.

How long will the old API exist?

1.0.3 available at: http://www.dobeash.com/download.html

Supports latest SQLite v2 API.

*** WARNING ***
Is not compatible with older versions of the SQLite DLL.

I expect that is due to changes in SQLite - it has changed the API 
a bit between 3.4.0 and 3.5.x

RebDB is memory-based, or if your DB structure and access is simple 
enoiugh just use sorted blocks. You really only *need* a DB if you 
require a complex access API such as SQL.

1.0.5 available at: http://www.dobeash.com/download.html


Mac OS X now uses the v2 API and newer dylib path. SQLite/version 
now contains version number as a tuple!

word wrap queries (like in the old amiga api) within AGG draw would 
be cool too... as in, what would the size of this text (or any gfx 
element, for that matter) be with current font/drawing settings. 
 and how many letters from a string fit within this box ? wrapped 
or not.

now to redesign the API. it's too clunky right now

Hmm interesting you say that. I was thinking about that myself, as 
I have also fallen in love with Opera, but it currently has pathetic 
plugin support (it doesn't even support the Mozilla standard, only 
the ancient Netscape 4 API).

Josh - Opera needs to be supported, definitely. The strange things 
is what you say, because the extended API announcement I pointed 
you to last time, was signed even by Opera company. Maybe you should 
check with Opera team ...

Pekr, regarding Opera: According to their plugin API page (http://www.opera.com/docs/pluginapi/), 
they only support NS4 w/LiveConnect. That's ancient.

Josh - I joined Opera's plug-in newsgroup and asked the question 
about the npruntime plugin api. I found someone was asking exactly 
the same in 2005. They said "I believe we are working on it.  However, 
I don't know how far we've come with this yet." I really don't understand 
such statements, that person does not know if something is, or is 
not going on in the company he works for.

That new scripting API doesn't work for me in the latest FireFox, 
so they may have not implemented it yet....for now, we're just using 
XPConnect.

btw - what advantage will npruntime version give us upon xpconnect 
one or old NS API one?

here's reply hopefully from Opera representative - 

> Hello guys,
> >

> > please what is the status of npruntime API extension? From following
> > link I can see, that Opera was part of the announcement:
> >
> > http://www.mozilla.org/projects/plugins/npruntime.html
> >
> > We would like to get Rebol working in browsers, so we are

> > investigating various browsers possibilities. It is a pity if 
Opera
> > still supports only rather arcane NS API.
> >
> > Thanks,
> > Petr



Opera version 9 supports the npruntime interface now.  Unfortunately,

it is not well tested on linux (at least), since I have not found 
any
plug-ins that use it.  Bug reports are welcome  :) 

eirik

All browsers in OSX use the mozilla plugin API.

Brian. Mashups (as I'm referring to) is the common term for webapps 
that utilise numerous webservices and combined in the browsers. But 
I hope you can come up with a security method that allows us to utilise 
advertising, google adwords-api, flickr, amazon-api, numerous maps, 
calendars. etc ; without having to combine on a single server before 
it goes out to the clients rebol plugin. I can do all this now in 
a browser, but I won't be able to with a rebol-plugin?

Henrik - why should it? There is no IE to support on other platforms. 
And imo other browsers on Linux/OS-X use NS compatible plug-in. And 
imo it should be even compatible API wise.

For NTLM authentication, isn't there some OS API to do that ?

I can't imagine that each program using Internet has it's own NTLM/Kerberos 
authentication scheme!!

Yes, I'm looking into both OS API and native methods.....

OK. I'm thinking about using Win32 HTTP/FTP upload/download API functions, 
which use the proxy settings set in Windows.....

No, getting the config won't be necessary. There is full support 
in Win32 to download and upload files via HTTP and FTP, and these 
API functions automatically use the Internet Configuration in Tools->Internet 
Options, which includes proxy.....

I need to run this by Carl, but my thinking is along the lines of 
a new option to 'read and 'write that says "use win32 HTTP/FTP API". 
If you choose that option, you get full proxy support in Windows....

With this approach, we're not building full auto-config/NTLM/Kerberos 
proxy support into REBOL, rather we're utilizing the OS API resources 
to do it all for us.

but does Windows http/ftp API limit rebol free socket capabilities 
or not? :-)

The problem is that today REBOL is doing everything itself. It is 
making the socket connection, sending the GET command, etc. In the 
process, it has to know everything about the proxy settings and do 
everything natively.


I am proposing adding new HTTP/FTP support that uses the Win32 API. 
No more socket communication within REBOL -- instead, Win32 does 
everything, including interacting with proxies.

Well, you tell me. Here are your options:

 1. Minor fix to get-net-info that reads correct registry values. 
 Does not handle auto-config, NTLM, or Kerberos.

 2. New refinements to 'read and 'write that use Win32 Internet API 
 to download and upload HTTP/FTP files. Uses whatever is supported 
 by the OS, including auto-config.

Would you prefer (1), (2), or both?

To clarify: I made a mistake above. There is nothing in get-net-info 
that needs fixing. The single question is: do you want a Win32-specific 
refinement that changes the read or write to use the Win32 HTTP/FTP 
API, and consequently enables full proxy support?

I want to make it clear that we are not promising these refinements 
or anything along those lines.. We may nix the whole idea. We just 
want to get your feedback on the idea. Would you like refinements 
that use the Win32 HTTP/FTP API, including proxy support?

If we have access to the win32 http api, we should get https as well...

win32 api https
 http://blogs.msdn.com/ie/archive/2005/10/31/487509.aspx

WinInet.dll offers a Win32 API for http, https, and ftp downloads 
combined with other API for caching and parsing.  It\u2019s a very 
popular binary, and in addition to being part of the IE platform, 
is widely used in Windows client applications for its Networking 
services.

of course, as for rebol itself, you can prepare your app ahead - 
it is still standard View 1.3.2 imo, just in form of a dll, being 
called via plug-in dll API

Terry: I'm about to release a new version of Cheyenne with a redesigned 
and more reliable RSP engine. I've also started documenting the RSP 
API and features (takes much more time than I expected).

See Cheyenne/docs/rsp.html for the new RSP API (the doc is half complete, 
I should finish it tomorrow and add a CSS)

Watch out in the rsp.html doc file, the "Session Object" table is 
correct, but all the detailled explanations for the session properties 
are incorrect (coming from the old and obsolete API). Sorry for that, 
it will be fixed in the final release of this document tomorrow.

I didn't had much time to work on an internal API for live changes 
in Cheyenne, but, in theory, you should be able to reload the entire 
Cheyenne and Uniserve engine without restarting and without loosing 
opened connections.

Several bugs fixed (including the sixteen.html counter bug). RSP 
API documentation updated and fixed, 75% completed, still needs some 
work to finish.

I'm looking at the rsp-api.html and don't see anything there

the current rsp-api doc is just an API reference documentation, I'll 
provide a more general explanation about RSP concepts and features 
separately in a few days.

I'll fix that for next release. It wasn't a priority for me until 
now, because I only use my own DB drivers which API differs a little 
from RT's ones.

I can't see what's causing your error, it may be related to another 
difference between odbc:// and my DB API.

/Command DB API is a de-facto standard. I didn't complied with that 
standard, just because I found it not handy the db-port / command-port 
approach ...so my fault ;-)

response/set-status 404 (see Response object API in %docs/ folder)

Cheyenne release v0.9.13 beta. Download at http://softinnov.org/tmp/cheyenne-r0913.zip

Changelog :


 o Session cookie management refactored. Cookies are now cached in 
 memory. 
	  Fixes all issues related to timezone.
	  

 o HTTPd request pipeline refactored. It's now more reliable, little 
 faster and

   able to handle extreme situations (stressing with FasterFox). Several 
   core parts
	  of Cheyenne have been touched, so watch out for regressions.
	  

 o Added 'forward method to RSP's Response object (now possible thanks 
 to the 
	  new pipeline engine).
	  

 o Internal modules API changed : 'deferred? property removed (not 
 needed 
	  anymore with new pipeline).
	  

 o Added 'on-status-code option in config file (see example in %httpd.cfg).
	  

 o do-sql now catches internal errors, so they can be more easily 
 located in 
	  calling context.

Marteen: about docs, the RSP API document will be published tonight 
with the new release. The module API is still incomplete and the 
general Cheyenne main doc is still pending (scheduled to be released 
for 13/06).

Cheyenne release v0.9.14 beta. Download at http://softinnov.org/tmp/cheyenne-r0914.zip

Changelog :

o response/forward improved : 

 - fully supports URLs as argument (can now forward to another virtual 
 host).
	- URL validity check (must have an explicit target).
	- protection against cycles.


o Command line option -p extended, now you can specify several listen 
ports separated
   by a comma (ex: -p 80,10443).


o New command line option -e : load and initialize Cheyenne without 
entering the

   event loop (needed for embedding Cheyenne in third party apps).


o Added a new experimental module: mod-embed. Purpose is to allow 
easy Cheyenne

   integration in third-party REBOL applications that require an embedded 
   web
   server. (Uncomment mod-embed in httpd.cfg file to activate it)


o Added %embed-demo.r file to show a sample of the mod-embed usage 
and API. 

o RSP: <% without %> eats all the memory. Fixed.

o URL-encoded request values were not parsed correctly. Fixed.


o RSP: fixed a typo in 'decode-params blocking the multipart data 
decoding and
   also a local word ('type) leaking in GC.

o UniServe's service startup refactored to be more flexible.



The new mod-embed is experimental. Please look at the %embed-demo.r 
file and send your feedbacks here.

The workaround is to call directly the win32 API to get the correct 
timezone offset, so requires /Library component.

If some of you needs to implement handlers now, just ping me here, 
and I'll write some preliminary docs on bg tasks API (quite short 
and simple in fact).

Even if you reimplemented TotalCommander in Rebol, you would still 
be dependant on the OS filesystem API.

The include2 api looks pretty clean and understandable.

then the ui just calls back the server via qtask api (blowdart)

but it reminded me of your doc, where you suggested to separate app 
logic and UI representation. I can imagine having rebol framework 
back-end, featuring various engines - callendaring, task management, 
general workflow engine etc., and API for user interface. And the 
client? - would be translated into web browser interface or represented 
by Rebol View UI. Possible? :-)

Norman, our new website (as opposed to our web service) will be up 
with docs in about 2 weeks...it will speak to our architecture, Mobile, 
API, etc.  We have hired several more people recenty who are working 
on this.

Graham, for my side, I still plan to support beer, I get the framework, 
and see the advantages.  We need our full API in place first.

It's a planned feature. It just needs a SQLite REBOL driver with 
an API compatible with my MySQL driver or RT's DB drivers.

New CureCode version released. Changelog : 0.9.7 - 11/04/2009


 o FEAT: Dismissed tickets are now filtered out from "Active Priorities" 
 and "Worst Severity" filters
	o FEAT: Current project name added to "Add Ticket" form.

 o FEAT: Reversed sort order for Versions and Categories lists in 
 admin page.

 o FEAT: Added an experimental API for getting tickets in REBOL format.

	o FIX:	Front page stats now count "dismissed" tickets as closed.

 o FIX:	Message "n ticket(s) found" fixed for localization, now translates 
 correctly in french.

CureCode API documented here : http://rebol.net/wiki/CureCode#API_documentation

Did anyone tried to play with CureCode's API yet? Should be fairly 
easy to make a VID-based popup notifier for new or modified tickets.

we still don't have an API for writing bots for Rebdev, though.

I've just built a direct printing library for R2, Windows only. It's 
a wrapper on Win32 Print API, so it supports all printers. It support 
a subset of Draw dialect as input. I was needing it to print reports 
for the project I'm currently working on. It still needs some additionnal 
work to be released publicly (like adding a port scheme layer for 
more intuitive usage).

My library is just a thin layer that maps Draw dialect to Win32 Printing 
API.

I had a quick look at XPS API, but it looked more complicated and 
required more work than GDI API. There was also the compatibility 
issue, I needed a solution that would work with any printer. I'll 
gave a deeper look at XPS latter.

Righ, gobs being lower level would require less work to map to OS 
Printing API.

Well, if you are using the OS's facilities for printing you are using 
the API version of the semantics, not necessarily the source. What 
really matters is the semantics - the source is just a generated 
representation.

Wrapping the windows printing api doesn't help linux users :)

It wouldn't be the wrapping of the Windows API that would help Linux 
users, it would be his initial work on making a Draw-like printing 
dialect. Defining the dialect is a large part of the process of supporting 
printing in REBOL. There will be non-Windows-specific parts of Doc's 
implementation that can be adapted to a general printing model for 
REBOL, one that can have multiple implementations with different 
backends. For that matter, there would need to be at least 3 backends: 
GDI (for Windows), Postscript (for Ghostscript) and PDF (for Mac 
Quartz), with a possible XPS backend as a minor variation on the 
PDF one.

Draw dialect maps very well with Windows drawing API (GDI). It's, 
in most cases, a one to one mapping.

Thanks but this isn't really such a great piece of code (Windows 
API is doing the real job), even if it fills a gap in REBOL (at least 
for Windows). Btw, in my company, we're using Gab's pdf-maker for 
years now to generate and print all our documents. I made this library 
only because I needed a direct printing solution for a customer and 
I must admit it was a fun work to do.

The underlying GDI API I've used does a lot more than needed, I should 
restrict its behaviour.