You've got it. Setting up aliases based on prefix at the top of the XOD
file was exactly the solution I had in mind to the verbose-site-ids
problem. Similarly in the code generator we just need to emit a macro
which hides the scary site namespace.
On Tue, Feb 12, 2008 at 06:04:50PM -0500,
On Sat, Feb 09, 2008 at 01:02:15AM +, Lalo Martins wrote:
Yet, you didn't address my actual point ;-)
I know what site IDs are supposed to be for. My question is -- do we
really want libraries to ship as a separate site each? I realise the
key space is pretty large, so polluting it
Also spracht Peter Amstutz (Mon, 11 Feb 2008 17:43:45 -0500):
With regard to shipping the private key, my thinking is that publishing
an API is like specifying a protocol, and that you really want a way of
unambigiously referring to a specific API as published by a specific
entity at a
Also spracht Lalo Martins (Sun, 10 Feb 2008 08:18:05 +):
This naming pattern unfortunately means you can't have two things
(class, function, namespace) on the same directory.
... two things (...) with the same name in the same directory.
best,
Lalo Martins wrote:
AIUI from IRC conversations, the site IDs won't actually be visible to
the application programmer later on; we'll deal only with IDs like /vos/
core/StringProperty. (I'm not sure about the code namespaces, but I
hope some simplification is intended there too ;-) ) Peter
Also spracht Reed Hedges (Sun, 10 Feb 2008 12:35:21 -0500):
Thanks! Does one just run voscodegen with the xod file as input to
generate the code?
$ cd debug/stage/bin
$ ./run.sh ./voscodegen -o ../../../src/app/helloworld ../../../src/app/
helloworld/HelloWorld.xod
best,
The new type IDs are still bothering me a bit too (among other things,
like the code namespaces). A huge advantage of the old user-invented
type names is that they were natural to understand and easy to remember.
We're going to have to do a lot of cutting and pasting, and when we
get one
Is there any rhyme or reason to site ids?
If all libraries will ship a separate site (as XOD or something) with
their OTDs, won't that pollute the site id space?
And aren't them bound to clash at some point? Maybe set up a registry of
library site ids somewhere in the website?
Or is this
On Fri, Feb 08, 2008 at 09:52:40AM +, Lalo Martins wrote:
Is there any rhyme or reason to site ids?
The current testing site ids are not true site ids. The site id is
actually supposed to be the public half of a public/private key pair
using elliptic curve cryptography. A 128 bit key
Yet, you didn't address my actual point ;-)
I know what site IDs are supposed to be for. My question is -- do we
really want libraries to ship as a separate site each? I realise the
key space is pretty large, so polluting it is probably no big deal, but
I see no big advantage in this case.
10 matches
Mail list logo
