Hello Hugh,

For starters, thanks for taking so much time.

On 3/14/07, Hugh Williams <hwilli...@openlinksw.com> wrote:

 Hi Emilliano,

See responses to your questions below inline:

On 13/3/07 21:41, "Emiliano Heyns" <emiliano.he...@gmail.com> wrote:

[Hugh] I presume you are enquiring about custom MetaData extract APIs ?
Their is not documentationon how this works but their source code for those
we have implemented to date are available in the source code. If you would
like specific details on location I can obtain this information for you ?


For now it's just good to know it can be done; when and if I get to the
point that I need them I'll go through the source and maybe ask again.


   1. If the execute property is set on an vsp(x) resource it is
   executed when accessed. How would I still get at the source for editing
   without disrupting execution by people just visiting?


[Hugh] As WebDAV uses the GET method for retrieval of a some content,
generally speaking their is no way to distinguish between 'edit' and
'execute' request. To allow execute & edit capabilities a special flag is
available for  virtual directories 'executable=yes' , which can be set with
a checkbox via the Virtuoso Conductor interface and overrides the execution
permissions check-box. You can then have a two Virtual Directories one for
executing the pages (i.e. URL which is exposed to public) which has the
flag set and create another Virtual Directory which is complementary of the
first Virtual Directory, but has the flag set to no and can be used for
editing. All the active pages must not have execute bit on, which will is to
allow second URL to return the source. The net effect being two URLs, one to
be used for editing and the other for viewing the content.


Great, that would work for me.


   1. I've dabbled a bit with SQL Server 2005, which has a hard 2GB per
   column limit. Does Virtuoso also have such a limit? If so, doesn't this
   hamper Virtuoso's use as a (WebDAV-based) document management system?

General

[Hugh] Virtuoso has the same 2GB limit, although this can be changed it
need be but would break backward compatibility.


Ouch, I'm going to hit that limit pretty soon. After the music server thing
I was thinking about extending the existing Virtuoso CMS stuff, but since
I'd also be hosting image galleries, the 2GB is not going to suffice. I
might have to look into creating a udt that stores the actual content
outside virtuoso. Not my preference, but appearantly the 2GB thing is not
uncommon.


   1. http://virtuoso.openlinksw.com/wiki/main/Main/VOSIntro
   
<http://virtuoso.openlinksw.com/wiki/main/Main/VOSIntro><http://virtuoso.openlinksw.com/wiki/main/Main/VOSIntro>
 mentioned 'hosting non-virtuoso content'. What does this mean? How would I
   use it?


[Hugh] This refers to content not stored in Virtuoso SQL using its
virtualization features to access data from non-virtuoso sources. This also
covers procy server I from of we servers via redirects etc.


Ah, but this is specific for the non-VOS version, right?


   1. In an interview by Jon Udell, Kingsley Idehen mentions a drag and
   drop db/form designer. Is a demo available for that? I'd truely love to see
   that!


[Hugh] The  refers to applications available as part of the OpenLink Ajax
Toolkits OAT, which is includes Database and Form Designer applications
amongst others enabling the graphical design of Database queries and forms.
This is and Opensource offering from OpenLink which can be downloaded from
the following URL:

http://oat.openlinksw.com


Pretty sweet!


   1. In the same interview, Kingsley likens Virtuoso to Zope. Does
   virtuoso implement something like callable objects in the database, or
   aquisition? Again, I'd love to hear about that! I have a bit of zope
   experience, and as sweet as it is, I just can't get over how disruptive
   changes between even minor versions are. Here's to hoping Virtuoso does
   better!


[Hugh] Virtuoso's User Defined Types(
http://docs.openlinksw.com/virtuoso/udt.html#udt)<http://docs.openlinksw.com/virtuoso/udt.html#udt%29>enable
 the calling of externally hosted functions/objects within the
Virtuoso space, and is compatible across releases thus we would not expect
you to have problems across releases.


Good, I'll have to go experiment with that.


   1. I'm not entirely clear on whether virtuoso-t is a single-database
   or a multiple-database server. Can a single virtuoso-t host multiple
   databases? If not, does that mean each database would need their own
   connection ports?

[Hugh] Multiple database instances can be start on the same machine using
the same virtuoso-t program with each instance being assigned a separate
server process.


Yes, by starting the same binary multiple times. But can a single running
instance of virtuoso-t host multiple databases (like most DB products I'm
familiar with), or does one instance service exactly one database?


   1. Can the hosted languages access all libraries? I'm thinking about
   doing some PDF reporting stuff for another project using Python PDF libs.

[Hugh] Yes, all libraries will be accessible in the same way they would be
if running natively.


Does this not open a path for security issues? SPs for other DB products can
in general not (without extra config) load external libraries, access the
filesystem, etc.

[Hugh] We are also not in favor of open source licensing change have been
bitten by this ourselves in relation to some of the opensource database we
work with. Thus if our open source licensing was to change most probably it
would be to relax the terms,


But currently everyone working on Virtuoso itself is with OpenLink? No
outsiders involved?

and in answer to your final question below you are currently currently the
connection libs are covered under the GPL license but we are currently
considering making them LGPL .

That's OK, I'm still drafting the architecture at this point, so no rush.
I'm OK with releasing my stuff under the GPL, it's just that I'll have to be
careful about what languages and libs I choose to combine.

Thanks again,
Emile

Reply via email to