Saving Outlines

  So I've taken a first look at scripting2.root.
  Locating scripting2Suite.editor.save is easy.
  Saving to the scripting2 server seems very easy as well: provided we have the outline in OPML format, and that its first summit has the proper scripting2 specific attributes (which it would have if we loaded it from scripting2 in the first place), all we need is to invoke the scripting2.savePost method on the scripting2 XMLRPC server, passing the username and password along with the OPML text.
  Assuming we are performing the save outside the scripting2 tool, this raises a few questions:
  1/ How do we get the host name and root url of the XML-RPC server responsible for publishing the OPML ?
    Within the tool, it is a preference in scripting2Data.editor.prefs.server.
    I understand that for now there is only one edit.scripting2.com/RPC2.
    But hopefully, this will change as others start deploying the tool, possibly in EC2 AMIs.
    So, when we grab the published page's source OPML with a bookmarklet, we need a way to identify which server is responsible for its publication.
    It could be an additional optional attribute in the outline's first node. I haven't noticed anything at this point in the outlines that were saved to iJot.
    The rule could be: the 'xmlrpcserver' attribute identifies where to send save commands if present, otherwise the 'default' value of xmlrpc://edit.scripting2.com/RPC2 is assumed by the 'foreign' code.
  2/ Now for something trickier: how do we manage authentication from an external system ?
    scripting2Data.editor.prefs.username and scripting2Data.editor.prefs.password are part of the tool.
    They are also registered in the copy of the tool responsible for the online rendering, probably in scripting2Data.server.users.
    What we need is a more or less secure way of authenticating a user with the online tool from an external system.
    Dave, do you have anything in mind for an authentication API ? Have you already baked something, or do you want me to code one for you (I would need to ask a few more questions :-) ?
    Should we use a Web 'standard', such as some version of openID or something ?
    Well, on second thoughts, there is no point since the current savePost method requires the transmission of username and password in the clear,
    So the external tool may just prompt for a username and password, then send the savePost call along, and just display an error code if authentication fails when processing the request. Very un-secure, but also very workable :-)
      I do not think security is a top concern when bootstrapping. We will have time to work out something token based later if users clamor for it.